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ABSTRACT 


Despite the increasing emphasis by the military on joint force operations, existing 
modelling and simulation programs, including NPSNET, fail to address joint operations 
and crew coordination. The problem is that previous work on NPSNET, the virtual 
environment and visual simulation platform developed by the Computer Science 
Department at the Naval Postgraduate School in Monterey, Cahfornia, has focused 
primarily on individual ground force elements with little emphasis on naval forces or crew 
concepts. This restricts the practical use of the system to ground force training while 
ignoring joint force training with sea and air components and between crew members. 

One solution to is expand the capability of NPSNET by incorporating a variety of 
vehicles from different components of the military with the added capability of multiple 
workstation control of a single vehicle. The approach taken is to expand NPSNET to 
simulate helicopter Anti-Submarine Warfare. This work focuses on realistic helicopter 
flight control, multiple workstation control of a single vehicle, and interface design 
between workstations controlling one vehicle. 

NPSNET has become a more useful training tool for today’s military forces by 
implementing more realistic helicopter flight controls and adding joint mission capabilities. 
The significance of this work is that a broad range of forces can receive valuable joint 
training and crew coordination training conducted in a virtual environment. 
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[. INTRODUCTION 


A. BACKGROUND 

One of the goals of virtual reality is to present to users an interactive environment 
closely resembling the real world. While not as real as the world we live in, we always 
strive to make it so, giving the user of the environment some sense that his interactions are 
real. This matches closely with a goal of military computer simulation: provide as real a 
training environment as possible so as to maximize the training benefit to the individual and 
minimize the risks inherent in real world training. With the military’s increasing emphasis 
on joint operations, conducting training exercises in real environments between services, 
or between different units in the same service, is vitally important, but logistically difficult, 
if not impossible. This is made more difficult by the ever increasing demand for the U.S. 
military to conduct extensive operations on unfamiliar foreign soil or waters with little to 
no advance notice. 

NPSNET is a distributed virtual environment and computer simulation research 
effort which came about in response to these goals and requirements. By being distributed, 
military units at distant locations can interact with each other in a common and realistic 
virtual environment, providing useful training between distinct units without the need for 
being in the same physical location [ZYDA94]. The virtual environment gives the user the 
feeling of being in the real world with the same freedom that he would have if he was out 
in the field. This research is an attempt to expand the scope of NPSNET’s current 
implementation, which is primarily geared toward ground-based forces and operations, to 
include naval helicopter based anti-submarine warfare (ASW) forces and operations. 




MOTIVATION 


1. Expansion of NPSNET’s Scope 

Joint operations are becoming the primary focus of the military. For example, land, 
air, and sea forces from the Army, Navy, Air Force and Marine Corps, and armed services 
from several foreign countries, were closely integrated in the U.S.-Iraqi War in 1991. 
Training and rehearsal in a virtual environment representation of the region could be used 
to prepare the various components of a joint military force by giving them a basic idea of 
the terrain and what to expect from other services and units during battle. This is not as 
realistic as actuaOy going into the real world environment of concern, but it is a much more 
cost effective training tool than assembling all the involved units at the location, whether 
that be land, sea, or air, or any combination of these. 

As already mentioned, NPSNET primarily simulates ground-based military 
operations. Tanks, foot soldiers, and helicopter gunships represent the bulk of what can 
currently be simulated. This does not represent the current trend in tactical training and 
simulation described above. To solve this problem, NPSNET needs to be expanded to 
involve more platform types and more terrain databases. This would allow a wider variety 
of military units representing many more operational platform types than currently 
implemented, to benefit from the joint training that NPSNET can provide. Adding 
helicopter ASW functionality to NPSNET is a step in this direction. 

2. The Need for a Realistic Helicopter Control Model 

As stated above, NPSNET is a computer workstation based simulation program of 
various operational platforms. To provide realistic simulation to users of the system, the 
user must be able to control the vehicle they are simulating in a manner closely 
approximating the way they would operate the actual vehicle they use. This maximizes the 
training benefit of the system by realistically simulating as many aspects of the actual 
system as practicable, limited by the capabilities of the workstation on which the simulation 
will run and the input devices utilized. 
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The current implementation of helicopter operations in NPSNET is based primarily 
on tactics. An AH-64 helicopter can fire missiles, shoot a machine gun, or drop bombs. 
With helicopter ASW functionality added to NPSNET, an SH-60 helicopter can drop 
sonobuoys or torpedoes to find a submarine or fire an anti-ship missile. In both of these 
cases, however, only half of what is important to a tactical simulation is actually being 
simulated, which happens to be the tactics themselves. Equally as important to realistic 
simulation is actual control of the vehicle, in this case the helicopter. 

The current model of helicopter control in NPSNET is the same as that for any fixed 
wing aircraft in the system. While this may provide enough realism and accuracy to the 
simulation of a fixed wing aircraft, it is not at all realistic for helicopter control, which is 
more complex. The solution to this problem is to change the control paradigm currently 
used for helicopters to one that more accurately reflects how a real helicopter is flown. This 
provides a much greater level of realism to the user, thereby increasing the level of training 
received. 

C. OBJECTIVES 

The objective of this research is the design and construction of an interface to 
simulate helicopter ASW in NPSNET. This interface provides to a user on a single 
computer workstation or multiple users at different workstations representing one ASW 
helicopter the capability to realistically prosecute a subsurface contact by utilizing the basic 
ASW capabilities added to the system. The interface provides the ability to exercise aircrew 
concepts regardless of whether a single workstation or multiple workstations are 
participating in the simulation. Another objective is to increase the realism of operating any 
helicopter in NPSNET by changing the control inputs to inputs representative of a real 
helicopter. 

D. CHAPTER SUMMARY 

Chapter II provides an overview of NPSNET, including previous work forming the 
basis of this research effort. Chapter III describes some basics of helicopter control and 
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crew concept. Chapter IV provides an overview of helicopter based ASW operations. 
Chapter V details the implementation of helicopter control developed from this research, 
Chapter VI describes the interface designed for multiple workstation helicopter ASW 
simulation. Chapter VII provides a description of the use of the designed ASW system. 
Chapter Vni details results of testing of the system and presents conclusions of this 
research and recommendations for follow on work. 
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II. PREVIOUS WORK 


A. NPSNET OVERVIEW 

The Naval Postgraduate School Networked Vehicle Simulator IV (NPSNET-IV) is 
a three-dimensional virtual environment and visual simulation system. Using the 
Distributed Interactive Simulation (DIS) protocol, it operates in real-time over large-scale 
networks on commercial, off-the-shelf Silicon Graphics workstations [ZYDA95]. 

In operating NPSNET-IV, a user on a workstation initializes the system to simulate 
a specific vehicle in a specific terrain database. Currently, the user can choose among a 
number of aircraft, ground vehicles, or a synthetic human. The choice of terrain database 
includes a generic training database, a database for Fort Hunter Liggett, California, and a 
database for Fort Benning, Georgia. Once the system has been initialized, the user has a 
view of the virtual environment, which is the terrain database selected, from the vehicle 
chosen. He can then move around in that virtual environment with an amount of freedom 
based on the properties of the vehicle his workstation is simulating and can fire the weapons 
that vehicle has been programmed to use. 

When a user chooses to initialize the workstation as a helicopter, the functionality 
provided is that of a ground attack helicopter, either the AH-64 Apache or the NATO 
designated HIND helicopter. The weapons available include machine guns, missiles and 
bombs for attacking airborne or ground based entities. The vehicle is moved around in the 
virtual environment by “flying” the helicopter with the available input devices. These 
devices include a joystick and throttle, keyboard, or spaceball [ZYDA94]. All of this gives 
the user the look and feel of being in his helicopter operating inside the virtual environment. 

What has been described so far only represents one entity in the virtual 
environment: one helicopter in a specific terrain database. Another aspect of NPSNET-IV 
that needs to be described is the network: how other workstations and the vehicles they 





simulate can interact with the helicopter. Each workstation on the network that participates 
in the simulation runs its own NPSNET-IV executable. When started, the program searches 
the local network to see if other workstations are participating in a simulation with the same 
exercise number. If so, these workstations now participate in the same simulation. For 
example, if the helicopter was initialized using the same exercise number as another 
workstation, then these two vehicles can interact with each other. This interaction involves 
being able to see each other, fire weapons at each other, see explosions caused by each other 
and their results, or team up with each other against other entities in the simulation. 

All of this interaction is possible through the use of the DIS protocol over the 
network. Each workstation transmits DIS packets to inform other workstations in the 
simulation about the status of that vehicle. For example, when the helicopter makes a turn, 
the program sends a DIS packet onto the network indicating a turn. When the other 
workstations receive this packet, they update their representation of that vehicle so that it 
executes the same turn as the originator. This same scenario takes place for all dynamic 
events in NPSNET-fV. 

The DIS packets that are sent are called protocol data units (PDU’s). NPSNET-IV 
uses three of the available PDU types from the DIS protocol. These are the entity state 
PDU, weapon fire PDU, and detonate PDU [ZYDA94]. All of these indicate to other 
workstations in the simulation dynamic events that originate on the sending workstation. 
The result of this communication is that each workstation conducts the same simulation so 
that interaction among vehicles is as realistic as possible. 

Since NPSNET-IV runs over a network, simulating a single vehicle is only part of 
what it must do. Each workstation must also show its user the other vehicles in the 
simulation in a realistic manner. To prevent saturation of the network with traffic to 
constantly update the position of each vehicle in the simulation, each workstation maintains 
a low resolution model of the other vehicles in the simulation used to calculate the predicted 
position of those vehicles based on recent PDU’s it received. Each workstation also 
maintains two models of itself; a high resolution model to track its actual position in the 



virtual environment, and a low resolution model which uses the same prediction scheme 
noted above. This method of prediction is called dead-reckoning, and it keeps track of a 
vehicle’s position, attitude, course and speed by predicting from the data contained in entity 
state PDU’s [ZYDA94]. When the two vehicle models a workstation maintains of itself 
differ by a predetermined amount of error, or a certain amount of time has elapsed since the 
last update, a new entity state PDU is transmitted. This causes the other workstations to 
update their low resolution model of that vehicle and continue dead-reckoning from the 
current position stated in the PDU. 

As noted earlier, NPSNET-IV is a real-time system. Each workstation bases its 
simulation on its system clock. So regardless of the graphics frame rate that can be achieved 
on a particular workstation, the simulation is the same on all workstations. For the dead¬ 
reckoning procedures described above then, a workstation receives a PDU to update some 
other entity in the simulation. Since that PDU is no longer current due to network 
transmission delays, the workstation dead-reckons from the time listed in the PDU. This 
time represents the time that the entity state PDU was generated and hence, when the 
location information about that vehicle was valid. The effect of this dead-reckoning scheme 
is that one simulation can be conducted on a variety of workstations at once without 
sacrificing accuracy of the simulation. A lower-end, slower CPU workstation can provide 
just as much realism in the simulation as one executed on a higher-end, fast CPU and 
multiple CPU workstation. All workstations show the same vehicles behaving alike and 
place them in accurate locations since it is all based on time. 

The final part of the simulation that must be dealt with is the terrain. In NPSNET- 
IV, each workstation maintains its own copy of the terrain database. This allows for a high 
amount of detail when each workstation draws the terrain while at the same time preventing 
large amounts of network traffic that would be needed if the database were stored in a 


entral location. 





NPSNET PANEL INTERFACE 


In thesis work by Chris McMahan, a windowed subsystem of NPSNET was 
developed to provide a common interface for the various vehicles of a simulation 
[MCMA95]. This interface was constructed using Motif and the Viewkit Development 
Toolkit to separate the functionality of the interface from the simulation and visualization 
engines. The advantage of this approach is that it allows development of new interface 
components without sacrificing speed or efficiency in NPSNET. It also allows users to 
easily adapt to methods of controlling different types of vehicles without having to 
memorize the many keyboard commands now used to control vehicles. 

There are some disadvantages to this approach. First, use of this interface panel 
detracts from the realism of a simulation. When used as the primary interface for a vehicle 
in a simulation, a mouse adjusts the various components of the panel, which, in turn, 
controls the vehicle. Real vehicles use real controls. To simulate these vehicles realisticaEy, 
similar controls are needed to provide the user with the feel of the vehicle he is simulating. 
If the panel is used as secondary instrumentation for a vehicle, however, realism can be 
maintained while still providing more information to the user. 

Another disadvantage of the interface employed in McMahan’s research is that 
there is no concept of one panel controlling one vehicle while another panel controls 
another vehicle. The reason for this is that the communication between the panel 
application and NPSNET has no facility for identifying which packet goes to which entity 
of the simulation. In addition, when NPSNET sends packets to the panel, there is no 
identifying information about which entity sent the packet. The result of this is that the 
panel shows information from all entities in the simulation, and any controlling information 
sent by the panel to the entity goes to any entity that has remote control designated at 
initialization. Only one panel can effectively be used with one entity, while the rest of the 
entities have no panel associated with them in the simulation. 

Despite these drawbacks, the interface panel concept developed by McMahan is 
useful to this research as mentioned above: as secondary instrumentation to users of the 



ASW helicopter being developed. If the panel can be instantiated once for every ASW 
helicopter initialized, the door is open for two users to control the helicopter, one using the 
flight controls and visualization effects already provided by NPSNET, and the other 
controlling the ASW tactical situation from information provided by the interface panel. If 
the two users operating these functions can communicate through their respective 
interfaces, a realistic simulation can be conducted which provides a degree of crew concept 
needed to effectively prosecute a subsurface contact. 
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III. BASICS OF HELICOPTER FLIGHT 


A. INTRODUCTION 

To understand what is needed to make simulation of helicopters more realistic in 
NPSNET, on must first understand how a real helicopter operates. This chapter describes 
basic helicopter aerodynamics, helicopter flight control, and the major components of a 
helicopter. While not intended to be a comprehensive examination of helicopter flight, the 
information contained here is provided as background for the changes made to NPSNET 
helicopter simulation, as described in Chapter V. 

B. HELICOPTER AERODYNAMICS 

There are several techniques for describing the physics of flying helicopters. The 
most realistic method used today is “blade element theory”, which describes the 
aerodynamic elements of flight by dealing with the forces on each individual rotor blade 
[PROU86]. This method for calculating helicopter motion is used in modem flight 
simulators since it can provide a great deal of realism to the pilot in the simulation. While 
very complex, these types of simulators accomplish real time calculation and simulation 
through the use of specialized computing hardware. The design of these computer systems 
is specifically aimed at fast performance of complex integration to provide the most realism 
possible to pilots. 

The blade element method quickly becomes impractical when considering 
NPSNET, which must calculate motion for a variety of vehicle types using off-the-shelf 
computer systems over a networked environment. The comparative slowdowns caused by 
the use of these systems make the realism provided by the blade element method impossible 
to recreate. In addition, NPSNET was not designed to provide this level of detail to the 
individual user. 





A simpler method is the “balance of forces” method. This method describes motion 
resulting from the forces acting on an airframe. The major forces acting on a helicoter 
airframe are lift, thrust, drag, weight and torque. Representing these forces by vectors gives 
a much less complex description of aerodynamics in a helicopter, allowing faster 
computation and a more realistic simulation than is currently accomplished in NPSNET. 

Figure 1 shows a general description of the balance of forces on a generic airframe. 
Assuming in this general case that lift, weight, thrust and drag all act on the aircraft’s center 
of gravity (C.G.), steady state flight can be maintained if aU of these forces cancel each 
other out. Steady state flight is when there is no acceleration or deceleration, or constant 
altitude and constant velocity. In the diagram, if the lift vector is equal in length to the 
weight vector and in the exact opposite direction, the aircraft will not accelerate up or 
down. The same is true of thrust and drag: if they are equal in length but opposite in 
direction, the aircraft will not accelerate or decelerate in its forward motion. If both of these 
cases exist at once, the aircraft will be in steady state flight. 


Thrust — 


Direction of motion 

Figure 1: Generic Balance of Forces 



In a helicopter. Figure 1 changes slightly. Figure 2 shows how the same forces are 
represented in a helicopter. The main difference is that lift and thrust emanate from the 
center of the rotor on top of the aircraft, while weight and drag still originate at the C.G. 
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A Lift 



Direction of motion 


Figure 2: Helicopter Balance of Forces 

The following sections give descriptions of each force as they apply to the balance of forces 
method for describing the aerodynamics of helicopter flight. 

1. Weight 

The simplest of the forces in Figure 2 is weight. Weight is a force that originates at 
the C.G. of the helicopter and points to the ground. Weight comes from the following 
equation: 

F = m X a (Eq. 1) 

where: 

F = weight, the weight of the helicopter, 
m = mass of the helicopter, and 
a = acceleration, the acceleration of gravity. 

To overcome the weight of the helicopter and produce flight, the main rotor of the 
helicopter produces lift. When the amount of lift is greater than the weight, the helicopter 
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will climb. Conversely, when the lift is less than the weight, the helicopter descends. And 
when the two are equal, altitude is maintained. 

In helicopter flight, weight changes as fuel is used during a flight. As more fuel is 
burned, the helicopter becomes lighter. This results in less power required to maintain 
steady state flight since the amount of lift needed to offset weight becomes less. 

2. Lift 

The easiest way to describe lift is by describing how a helicopter hovers. In a 
helicopter, lift is produced directly by the main rotor. As power is applied by the pilot, more 
lift is created. When the amount of lift becomes greater than the weight of the helicopter as 
described above, the helicopter will climb. 

The reason this occurs is that each blade of the main rotor is an airfoil, just like the 
wings of a fixed-wing aircraft. With no power applied, the pitch of each blade is effectively 
zero, so no lift is produced by the main rotor blades. As the pilot applies power, the pitch 
of all the blades increases, so lift is produced. If enough power is applied, the rotor blades 
will produce enough lift to equal the weight, and a hover is produced. For example, if a 
helicopter weighs 20,000 pounds, the amount of lift required to hover is 20,000 pounds. If 
less than 20,000 pounds of lift is produced, the helicopter descends. If there is more than 
20,000 pounds of lift, it climbs. 

Lift is represented by a vector originating from the center of the main rotor. It is 
perpendicular to the plane of the main rotor blades and points up. 

3. Thrust 

Helicopters do not produce thrust like a fixed wing aircraft. Jets and propeller 
airplanes produce thrust by driving a large volume of air rearward while the stationary 
wings produce lift due to volumes of air flowing over them. In a helicopter, lift is produced 
when the main rotor blades move through the air fast enough to obtain sufficient airflow 
over them then drive the airflow downward by pitching the blades up. Thrust, however. 
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must be indirectly produced. The way it is accomplished is by tilting the main rotor from 
the horizontal plane. This is shown in Figure 3. 
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Figure 3: Lift vs. Thrust 


As can be seen in Figure 3, the total lift between the two helicopters is the same, as 
are their weights. The helicopter on the left has less pitch, so the effective lift, the vertical 
component of total lift, is only slightly less than if there was zero pitch. The horizontal 
component, effective thrast, has appeared as well. This helicopter will start to accelerate 
forward from the amount of effective thmst, but will start to descend slightly as the 
effective lift decreases enough to be unable to counteract weight. 

The helicopter on the right in Figure 3 has significantly more forward pitch than the 
helicopter on the left. The effect here is that there is significantly more effective thrust and 
less effective lift. The helicopter will accelerate faster and descend more quickly. 

One of the unique features of the helicopter is that thrust can be produced in any 
direction by tilting the main rotor in that direction, including backwards and sideways. This 
is shown in Figure 4. The importance of this unique quality can be seen in the helicopter’s 
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ability to ho ver. By tilting the main rotor in the desired direction, the helicopter can be made 
to fly sideways or even backwards. 



Figure 4: Backwards and Sideways Thrust 


4. Drag 

As shown in Figure 2, drag is the force that thrust must counteract to provide 
acceleration and constant state velocity. Drag is opposite to the direction of motion. The 
amount of drag is dependent on the magnitude and direction of the helicopter’s velocity and 
the angle of attack of the helicopter’s fuselage to the oncoming airflow. As velocity 
increases, drag on the fuselage increases, resulting in the need for more power to go faster. 
In a similar manner, drag is at a minimum when the fuselage is heading forward. When 
flying sideways, the cross-sectional area of the fuselage into the airstream is much larger, 
resulting in higher drag. Therefore, it takes less power to fly forward than it does to fly 
sideways at the same speed. 
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5. Torque 

Another major force produced by a helicopter is torque, as illustrated in Figure 5. 
The engines drive a transmission which spins the main rotor in a counterclockwise 
direction. This spinning causes the fuselage to try to rotate in the opposite direction, 
clockwise. If this torque force isn’t counteracted, the helicopter would spin out of control. 



Figure 5: Helicopter Torque 


There are several ways modern helicopters counteract this torque force. The most 
common way is through the use of a tail rotor. This anti-torque device is mounted on the 
tail of the helicopter and is oriented parallel, or nearly parallel, to the fuselage, as in Figure 
5. The tail rotor produces thrust counterclockwise which pulls the tail end of the fuselage 
preventing the spinning. So it provides directional control for the fuselage, both in a hover 
and in forward flight. 

Another way that main rotor torque is counteracted is to have two main rotors 
spiiming in opposite directions. Since they spin in opposite directions, the torque that each 
produces is counteracted by the other, resulting in no torque on the fuselage. A newer 
method of counteracting torque is the NOTAR system, where a jet engine serves the same 
function as the tail rotor. Located in approximately the same position as a tail rotor, it 
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produces anti-torque by pushing air away from the direction of rotation desired for the 
fuselage. This pushes the fuselage in the correct direction to maintain directional control. 

C. HELICOPTER CONTROL 

Now that all of the aerodynamic forces have been explored, how are these 
controlled to actually fly a helicopter? This section describes the common controls used by 
most helicopters: the collective, the cyclic and the rudder pedals. These control devices are 
shown in Figure 6. 
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Collectivt 


The collective controls the pitch of the main rotor blades. Controlled by the left 
hand, the collective is moved up and down to increase or decrease the pitch of the blades 
all the same amount, or collectively. This increase in pitch increases the lift produced by 
the main rotor and gives the helicopter the ability to climb. Similarly, moving the collective 
down decreases the pitch on the main rotor blades producing less or no lift, resulting in a 
descent. 


2. Cyclic 

The cyclic provides the pitch and roll control of the helicopter. By moving the 
cyclic to the left or right, the pitch on each of the main rotor blades is adjusted so that the 
main rotor disc tilts the same respective direction. Tilting the main rotor in this fashion rolls 
the fuselage and results in a turn or a slide. 

Pitch is controlled in the same way as roll. If the pilot wishes to pitch the nose of 
the helicopter down, he pushes forward on the cyclic. This causes the main rotor blades to 
change pitch in cycle, driving the nose of the helicopter down and accelerating the 
helicopter. 

Pitch and roll commands through the cyclic can be combined as well. For example, 
forward pitch and left roll can be commanded for by moving the cyclic to the forward left 
position from its center. Any combination of pitch and roll can be input, which tilts the main 
rotor in the desired direction producing acceleration in that direction. 

3. Rudder Pedals 

The rudder pedals provide directional control by changing the pitch on the tail rotor, 
changing the amount of anti-torque as described earlier. Generally, with the rudder pedals 
in the center position, enough anti-torque is produced for the fuselage to maintain constant 
heading. Pushing the left pedal forward increases the amount of anti-torque, turning the 
fuselage to the left. Pushing right pedal turns the helicopter to the right by decreasing anti¬ 
torque. 
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4. Combining Controls 

In any aircraft, changing control to produce one desired effect usually requires at 
least one other control movement to maintain steady flight. One example would be using 
the collective to start a climb. When the collective is raised, the pitch of the main rotor 
blades increases to produce more lift. A climb results. One side effect of increasing the 
collective is a corresponding increase in torque. This is because the pitch of all the main 
rotor blades increase and more power is required to keep them turning at a constant rate. 
This results in more torque on the fuselage, so it begins to spin slowly to the tight. To 
counteract this, increases in collective are usually accompanied by adding left pedal. This 
helps the helicopter maintain a constant heading. 

Another example is the relationship between cyclic pitch and collective. If the pilot 
wishes to accelerate forward but maintain his current altitude, he must push the cyclic 
forward to tilt the main rotor forward. As described earlier, this increases the effective 
thrust produced by the main rotor and decreases the effective lift. To maintain the current 
altitude, the pilot must then increase the amount of effective lift by raising the collective. 
Finally, the situation described above occurs due to the collective being increased, so left 
pedal must also be applied to maintain heading. 

5. Engine Control 

Another concept that should be explained is the role the engines play in helicopter 
flight. In jet aircraft, the amount of thrust is directly related to the speed of the engines. If 
the pilot wishes to go faster, he increases the throttle to speed up the engines, which 
produces more thrust. 

In a helicopter, however, more lift is produced by increasing the pitch on the main 
rotor blades. As was stated earlier, the main rotor blades spin at a generally constant rate. 
The engines drive a shaft which drives a large reduction gear transmission. This 
transmission spins the main rotor and the tail rotor. Since it is desired that the main rotor 
spins at a constant rate, the engines run at a constant speed. Controlling the pitch of the 
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rotors is accomplished through direct linkages to the cyclic, collective, and rudder pedals. 
The only times that the speed of the engines deviates from their desired constant speed is 
during start-up, shutdown, and engine malfunction. In normal flight regimes, engine speed 
is not adjusted, so it is unrelated to control of lift and thrust. 

6. Maximum Forward Airspeed in Level Flight 

This is another important concept in helicopter flight. There are two limits related 
to this concept: an aerodynamic limit and a control limit. 

The aerodynamic limit is related to the spinning of the main rotor blades and is 
called blade stall. Blade stall is defined to be the tendency of the retreating blade to stall in 
forward flight [NTPS90]. Figure 7 shows the difference between the speeds of the main 
rotor blades relative to the oncoming airflow. The airspeed of a rotor blade is calculated by 
adding the rotational speed of the rotor blade to the forward airspeed of the helicopter. 
When the helicopter is in a hover, as in Figure 7a, forward airspeed of the helicopter is zero. 
Therefore, airspeeds of the advancing and retreating blades are the same. In fact, the 
airspeed of any blade throughout the 360 degrees of rotation is the same. 

In forward flight, however, the advancing blade is rotating into the oncoming 
airflow while the retreating blade is rotating away from it. Figure 7b shows that the 
advancing blade has a much faster airspeed than the retreating blade. The airspeed of the 
retreating blade is calculated by subtracting the forward airspeed of the helicopter from the 
rotational velocity of the blade since it is opposite in direction to the oncoming airflow. The 
result is that the retreating blade must increase pitch to maintain the same amount of lift as 
the advancing blade. If the forward airspeed is too high, the increase in pitch of the 
retreating blade will cause it to stall, or lose its ability to produce lift. The advancing blade 
will produce a high amount of lift, even at low blade pitch angles, since its airspeed is so 
great. Since one side of the aircraft has lift and the other side does not, such an airspeed will 
cause the helicopter to depart from controlled flight. Due to the fact that the effect of each 
main rotor blade on the total lift is manifested 90 degrees later, the helicopter nose will 
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pitch up when the retreating blade stalls. This has the effect of decreasing forward airspeed 
thus increasing the relative airspeed of the retreating blade. Thus, the stall condition is 
automatically corrected. However, the forces on the main rotor system during this 
transition from normal flight to stall and back can result in catastrophic damage. Hence, 
helicopter flight manuals limit the forward airspeeds that a pilot is allowed to fly so that this 
blade stall condition is avoided. [NTPS90] 



The other limitation on forward airspeed is a result of control limits. As forward 
airspeed increases, the pilot must increase collective to maintain altitude, as described 
earlier. If the helicopter is heavy enough, the collective will reach the upper limit of its 
control range before blade stall airspeed is reached. In this case, maximum forward 
airspeed in level flight is limited by the physical control movement limit instead of the 
aerodynamic limit of blade stall. 


22 




D. HELICOPTER COMPONENTS 


All modem powered aircraft are made up of components necessary to stay airborne 
in level flight. These consist of the fuselage, engines, some type of airfoils, and the cockpit. 
These components are present in fixed-wing aircraft and helicopters, but their .stmcture and 
function can differ. Figure 8 shows these components on a helicopter. 



Figure 8: Helicopter Components 


The purpose of a fuselage is the same for a helicopter and fixed-wing airplane: to 
house crewmembers and cargo, and to serve as an attachment point for the externa] 
components of the aircraft. In a helicopter, the engines, rotors, and transmissions are all 
attached to the fuselage. In addition, all electrical components and control linkages are 
inside the fuselage. 

The next major component of a helicopter is the engine. This is usually a gas 
turbine, or “jet” engine, and many helicopters have two or more engines. The purpose of 
the engines is to drive the thrust producing component of aircraft. In a jet airplane, the thrust 
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producer are turbines internal to the engine, and in a propeller airplane, it is the propeller. 
In a helicopter, this is the rotor system. 

The rotor system is a component that is unique to helicopters. Most helicopters have 
a rotor system composed of a main rotor and a tail rotor. The main rotor is a series of large 
blades that spin to produce both lift and thrust. When the pitch on the blades is increased, 
the blades produce more lift. When the blades are tilted, thrust is produced in the direction 
of the tilt. 

The tail rotor is the anti-torque device on a helicopter. By pulling/pushing the tail 
of the fuselage opposite the direction resulting from the torque produced by the main rotor 
blades, directional control of the helicopter is achieved. 

Finally, the cockpit is the location where the pilots sit to control the aircraft. An 
example of a cockpit is shown in Figure 6. The cyclic, collective, and rudder pedals are 
located in the cockpit, with duplicate sets for the pilot and copilot. Both the pilot and copilot 
have fun control capability over the helicopter. In addition to the flight controls, other 
components located in the cockpit are flight and engine instruments, electrical controls and 
circuit breakers, and tactical controls. The cockpit contains ample windows for the pilots to 
see forward, up, down, and to the side. This allows them to fly in any direction and land in 
any suitable location. 

E. SUMMARY 

Although many of the key concepts of helicopter aerodynamics and flight have 
been introduced here, much of the detail has been left out. Only basic concepts were 
addressed in the context of NPSNET, so only those concepts were explained in any detail. 
More complex concepts, like extreme aerodynamic situations, emergency procedures, and 
autorotations, were not introduced as they are beyond the scope of this research. 



IV. BASICS OF HELICOPTER ASW 


A. INTRODUCTION 

The other portion of this research involves simulating a helicopter conducting an 
anti-submarine warfare (ASW) mission. To understand the simulation system that is 
implemented, this chapter describes the components of an ASW mission: the flightcrew, 
the sensors, and the weapons. The descriptions given are specific to the SH-60B helicopter, 
but generally apply to most modem ASW helicopters. 

B. HELICOPTER ASW FLIGHTCREW 

The flightcrew of an ASW mission in an SH-60B helicopter consists of three 
members: the pilot, the Airborne Tactical Officer, and the Sensor Operator. Each has 
specific responsibilities in an ASW mission. 

1. Pilot 

The pilot performs the flight maneuvers of a mission. His primary responsibility is 
the safe conduct of the mission, and he must coordinate the tactics used during the flight 
with the ATO. [LWSM92] 

2. Airborne Tactical Officer (ATO) 

The primary responsibility of the ATO is the tactical conduct of the ASW mission. 
This includes deciding where to deploy sonobuoys, maintaining tracks on submarine 
contacts, managing use of all helicopter sensors, navigation to target areas for employment 
of sensors and weapons, directing weapon delivery and evaluation of attacks. Another 
important responsibihty is to back up the pilot in safe conduct of the mission. [LWSM92] 
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3. Sensor Operator (SO) 

The SO’s primary responsibility is to operate the aircraft’s sensors and monitor the 
status of the system. He controls the radar/IFF system, analyzes data from any sonobuoys, 
controls the MAD system and analyzes its data. [LWSM92] 

4. Aircrew Coordination 

One of the most important aspects of safe and successful completion of an ASW 
mission is aircrew coordination. The concept is based on each member of the flightcrew 
taking care of his own responsibilities during the mission while supporting the other 
members of the flightcrew in their responsibilities. 

Crew coordination works like this: the pilot operates the flight controls as his 
primary duty. He also helps the ATO in his duties by keeping the helicopter at an optimum 
altitude and location to accomplish the next task of the mission. This is so sonobuoys or 
torpedoes can be launched quickly when needed. The pilot also maintains a lookout for 
possible visual contact with a submarine, either by seeing one underwater or by seeing its 
periscope. 

The ATO controls the conduct of the tactical portion of the mission. For his part of 
crew coordination, he backs up the pilot on the flight instruments so that safety of flight is 
maintained. If the pilot flies the helicopter into an unsafe situation, the ATO is responsible 
for notifying the pilot or taking the control of the helicopter to get it back in a safe flight 
regime. 

In addition to operating the helicopter’s sensors, the SO aids the ATO by giving 
advice about the deployment of sonobuoys and weapons based on the information being 
received by the sensors. He also informs the pilot and ATO of equipment malfunctions or 
failures that affect the mission or the safety of flight. 
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C. HELICOPTER ASW SENSORS 

The SH-60B helicopter sensors for use in ASW missions are sonobuoys, the radar/ 
Identification Friend or Foe system, and the magnetic anomaly detector system. This 
section gives a brief description of each of these. 

1. Sonobuoys 

The primary ASW sensor for the SH-60B is the sonobuoy. A sonobuoy is an 
acoustic underwater sensor used for detecting submarines. The sonobuoy is a cylinder 
about forty inches long and eight inches in diameter. When launched from the helicopter 
in-flight, it falls until it hits the water, at which point the cylinder deploys a float to stay on 
the surface of the water. This float contains a radio transmitter for transmitting information 
back to the helicopter. The sonobuoy also deploys an underwater microphone, called a 
hydrophone, several hundred feet below it to listen for acoustic signals. 

There are two kinds of sonobuoys used by the SH-60B helicopter: active sonobuoys 
and passive sonobuoys. The passive sonobuoy can only receive acoustic signals, as shown 
in Figure 9. Any acoustic data received by the hydrophone is transmitted back to the 
helicopter via the radio transmitter. Computers in the helicopter analyze the signals and 
transform them into usable information for the aircrew. The information tells the aircrew 
the bearing from the sonobuoy to the subsurface contact. [LWSM92] 

An active sonobuoy transmits a sonar signal from its hydrophone into the water, 
then listens for the echo of that signal. The echo of the sonar signal is received when it is 
reflected off of an underwater contact back to the hydrophone as in Figure 10. The data is 
transmitted back to the helicopter via the radio transmitter and, when analyzed, gives range 
and bearing information from the sonobuoy to the submarine. [LWSM92] 

The SH-60B helicopter can caay and launch any combination of up to 25 active or 
passive sonobuoys. The sonobuoy launcher is located on the left side of the fuselage, as 
seen in Figure 8. [LWSM92] 
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2. Radar and Identification Friend or Foe (IFF) System 

The radar system is used to detect surface or airborne contacts 1LWSM92]. In the 
ASW mission, the radar is used to detect surfaced submarines or enemy ships. 

The IFF system is located on the radar and is used to identify whether potential 
threats are from enemy forces or friendly forces [LWSM92]. The system, like the radar, 
does not have underwater capability, so its use in ASW is limited to identification of 
airborne and surfaced contacts, including surfaced submarines. 

3. Magnetic Anomaly Detector (MAD) 

The MAD system is designed to detect submarines by measuring the earth’s 
magnetic field. It accomplishes this by detecting disturbances in the earth’s magnetic field 
caused by a submarine. The system then gives the aircrew a location at which the 
disturbance occurred. [LWSM92] 
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D. HELICOPTER ASW WEAPONS 

1. Mk 46 and Mk 50 Torpedoes 

The torpedo is the primary ASW weapon used by the SH-60B helicopter. The 
torpedo is launched from pylons on either side of the helicopter fuselage. When launched, 
the torpedo falls unguided to the water. After water impact, it uses active sonar to home in 
on subsurface contacts. The launch point of the torpedo is determined by the ATO based 
on his track of the submarine and the capabilities of the torpedo that will be launched. 
[LWSM92] 

Details about search patterns, acquisition ranges, run times and speeds of either the 
Mk 46 or Mk 50 torpedo are classified and beyond the scope of this research. The 
description given above is general and the extent of what will be simulated as a result of 
this research. 
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2. Penguin Missile 

The only other ASW weapon capable of being carried on the SH-60B is the Penguin 
missile. This is an infrared homing, air-to-surface missile. Launched from pylons on the 
fuselage, the missile is a “fire and forget” weapon, meaning that once it is fired, it is not 
dependent on the helicopter for any information or guidance. Prior to launch, though, the 
missile receives aircraft velocity, heading and altitude information and targeting 
information from the SH-60B weapon systems. This information is used by the missile to 
align its inertial navigation system and to navigate to the target unaided. [LWSM92] 

E. SUMMARY 

This chapter describes the tools used in prosecuting an ASW threat. Most of the 
actual tactics involved are classified and beyond the scope of this research. The purpose 
here was to give a basic knowledge of the personnel, sensors, and weapons needed to 
successfully track and attack a subsurface contact so that they could be reasonable 
simulated in NPSNET. Implementation of classified tactics and sensor/weapons is 
independent of the system developed for NPSNET by this research. 
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V. HELICOPTER CONTROL MODELLING IN NPSNET 

A. PREVIOUS HELICOPTER CONTROL METHODOLOGY 

Motion of helicopters in NPSNET prior to this research was based on a single vector 
representing the velocity of the helicopter. The vector is oriented from the center of the 
helicopter through its front, as shown in Figure 11. Its direction in NPSNET world 
coordinates is calculated from the heading, pitch, and roll angle values as determined from 
joystick input. Always being oriented out of the front of the helicopter, however, means that 
the it is limited to motion forwards and backwards. 



Y-axis: 

velocity 


Figure 11: One Vector Control Model 
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The speed of the helicopter, represented by the velocity vector’s magnitude, is 
determined by the throttle setting. It can vary anywhere from zero to the maximum speed 
of the helicopter, defined at compile time to be 100 m.p.h., regardless of its attitude. This 
further limits the helicopter to forward motion without the capability of going backwards, 
something real helicopters are quite capable of. 

Another problem here is that this model allows the simulated helicopter to remain 
stationary in space, simulating a hover, regardless of its attitude. As explained in Chapter 
ni, however, real helicopters cannot hover at pitch and roll settings other than zero. A 
helicopter must first decelerate to zero airspeed then set its hover attitude. Any other pitch 
and roll setting causes the helicopter to accelerate out of a hover. 

The result of this model is that the helicopter has freedom of motion in pitch, roll, 
and heading angles, and in its positive y axis only. A new model was needed to accurately 
model how real helicopters can move. 

B. NEW HELICOPTER CONTROL METHODOLOGY 

This section describes the methodology for calculating the helicopter’s motion. It 
describes how the control data from the joystick, throttle and rudder pedals is interpreted to 
calculate velocity. 

Real helicopter motion, described in Chapter HI, has freedom of motion in pitch, 
roll, and heading angles as well as positive and negative x, y, and z axes. This allows the 
helicopter to slide left and right (x axis), go forward and backward (y axis), and go up and 
down (z axis). This unique quality of helicopters allows independent motion in any of these 
axes. 

To accurately model this ability, a four axis system was developed. This model, 
shown in Figure 11, uses control inputs to calculate the speeds in the x, y, and z axes, and 
is based on the balance of forces theory of aerodynamics described in Chapter HI. The first 
step is to extract the control input data and convert that into magnitudes for the four vectors 
and into heading pitch and roll angles. 
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Figure 12: Four Vector Control Model 

1. Flight Control Data 
a. Joystick Input 

Figure 13 shows how the raw data from the joystick gets converted into 
values for the x and y axes in Figure 11. The joystick is used to simulate a helicopter cyclic, 
which controls the helicopter’s pitch and roll. Raw data from the joystick ranges from -1.0 
to 1.0 in both the pitch and roll channels. In the pitch channel, -1.0 is returned by the 
joystick when it is pushed all the way forward, while 1.0 is returned when it is pulled back. 
The center position is 0.0, and values in this range indicate how far forward or backward 
the joystick is moved. The roll channel operates in a similar manner: -1.0 is the leftmost 
position, 0.0 is the center, and 1.0 is the rightmost position, with varying values in between. 
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The raw pitch and roll data is used to find the magnitude and then the 
direction of the forward and lateral velocity vectors. In calculating the vector magnitudes, 
raw pitch and roll data are first used to calculate forward and lateral change variables. The 
equations used are: 

Aforward = - (raw pitch data * 0.09) (Eq. 2) 

Alateral = raw roll data * 0.09 (Eq. 3) 

These equations represent the amount of change that will be applied to 
acceleration in each of these channels. For example, assume that the helicopter is at a 
constant speed with the joystick in the center position (raw pitch and roll are both 0.0). If 
the pilot wishes to decelerate, he pulls back on the joystick. The raw pitch data is now some 
value between 0.0 and 1.0, depending on how far the joystick was pulled back. As can be 
seen in Eq. 2, this value is multiplied by the dampening constant 0.09 then negated, which 
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results in a value between -1.0 and 0.0. This change variable is later added to forward 
acceleration, indicating that the acceleration should get smaller. In the case of the example, 
since the helicopter was at constant airspeed, there was no acceleration, so acceleration 
becomes negative and the helicopter decelerates as a result. This works in a similar manner 
for lateral acceleration, with the exception that the value is not negated, as shown in Eq. 3. 
The reason for this is that when the joystick is placed to the right of its center position, the 
raw roll data ranges between 0.0 and 1.0. This would indicate that the pilot wishes to 
accelerate to the right. The helicopter’s x axis is also positive on the right. So, the lateral 
change data is directly related to lateral acceleration. 

The next step in calculating the magnitude of the forward and lateral 
velocity vectors is to input the change values calculated above into the acceleration 
equations. These equations are as follows; 

forward accel = forward accel + (A forward * cos( roll angle) ) (Eq. 4) 

lateral accel = lateral accel + A lateral (Eq. 5) 

lateral accel = lateral accel + ( A lateral / forward speed ) (Eq. 6) 

In the example above, the forward change variable is negative since the pilot 
wishes to decelerate. As can be seen in Eq. 4, this value is multiplied by the cosine of the 
roll angle. This angle was calculated in the previous display frame and is used as a starting 
point for calculating the roll angle in the current frame. The cosine of the roll angle is 
multiplied by the forward change amount to reduce the amount of acceleration/deceleration 
as angle of bank increases. Angle of bank is a way to describe roll angles without the use 
of negative values. For example, 30 degrees of roll is the same as 30 degrees right angle of 
bank. Similarly, -30 degrees of roll is 30 degrees left angle of bank. 

To show why this cosine calculation is needed in the forward acceleration 
calculation, assume the helicopter is rolled to the right 90 degrees. To increase the rate of 
turn, the pilot puUs back on the Joystick. This is a common maneuver in forward flight; roll 
into an angle of bank, then pull back on the cyclic to increase the rate of turn. If the cosine 
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calculation isn’t made, forward acceleration will decrease and the helicopter will decelerate 
rapidly. In a real helicopter, this does not occur due to the fact that, at 90 degrees angle of 
bank, pulling back on the joystick will not result in the helicopter trying to climb. It only 
increases how fast it turns. By taking the cosine of the roll angle and multiplying it by the 
forward change previously calculated, the effect of the forward change variable is 
decreased as roll angle increases. 

Once the forward change value is multiplied by the cosine of the roll angle, 
this value is added to the forward acceleration value from the previous display frame. The 
effect here is that acceleration of the helicopter is smooth and reacts slowly to the input 
changes by the pilot. 

Calculation of lateral acceleration operates in a similar manner to forward 
acceleration except that there is no adjustment made as a result of roll. In Eq. 5, the lateral 
change amount has its full effect on acceleration when the helicopter is flying slower than 
25 miles per hour (m.p.h.). So, at low airspeeds, the helicopter can accelerate into a left or 
right slide at its maximum rate. As airspeed increases above 25 m.p.h., however, the effect 
of the lateral change amount on lateral acceleration is decreased by the amount of forward 
airspeed, as shown in Eq. 6. This simulates the airstream acting on the fuselage at higher 
forward speeds and thereby restricting lateral acceleration. Above forward speeds of 50 
m.p.h., lateral speed and acceleration are set to zero to make the helicopter easier to fly for 
non-helicopter pilots. 

To complete the calculation of the forward and lateral vector magnitudes, 
the forward and lateral accelerations, respectively, are dampened and added to the 
magnitudes from the previous display frame. The equations for calculating the magnitudes, 
which is the speed the helicopter will travel in its x and y axes, are as follows: 

forward speed = forward speed + ( forward accel * 0.1) (Eq. 7) 

lateral speed = lateral speed + ( lateral accel * 0.1) (Eq. 8) 
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Acceleration values are dampened in Eq. 7 and Eq. 8 before being added to 
previously calculated speed values to provide realistic helicopter acceleration based on 
control inputs. The magnitudes achieved from these equations are later used to scale the 
forward and lateral vectors, respectively, for ultimately calculating the helicopter’s 
velocity. 

As seen in Figure 13, the joystick data is also used to calculate heading, 
pitch and roll angles based on their values from previous display frames. No significant 
changes were made to these calculations from the previous helicopter control model as the 
angles calculated appear realistic enough for the model resulting from this research. The 
only change to these angle calculations was to add the capability to use rudder pedals, as 
explained in the following section. 

b. Rudder Pedal Input 

Raw data from the rudder control pedals varies from -1.0 (left pedal full 
forward) to 0.0 (pedals centered) to 1.0 (right pedal full forward). This data is used to 
calculate heading only, as shown in Figure 14. On the ground or at slow airspeeds (less than 
25 m.p.h.), raw data from the rudder pedals manipulates the heading angle from the 
previous display frame. This allows the helicopter to rotate around its z axis. 

At airspeeds higher than 25 m.p.h., raw rudder information is combined 
with heading and roll angle data, raw pitch data from the joystick, and the calculated 
forward airspeed to calculate the new heading. Most elements of this calculation are from 
the original helicopter control model. The last part of the equation (raw rudder data/ 
airspeed) has the effect of changing the heading based on how far a rudder pedal is pushed 
in. Pushing the left pedal forward halfway, for example, causes the helicopter to execute a 
moderate rate of turn to the left. Pushing the left pedal all the way forward, however. 
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Figure 14: Rudder Pedal Data Flow 


Dividing the raw rudder data by the calculated forward speed reduces the 
rate of turn as forward airspeed increases. For example, if the left pedal is pushed all the 
way forward at 30 m.p.h., the helicopter executes a moderate turn to the left. Then the 
helicopter is flying at 180 m.p.h. though, the same pedal position results in a very slow rate 
of turn. 

c. Throttle Input 

Raw throttle data is used to calculate the amount of thrust produced by the 
main rotor of the helicopter, which represents the magnitude of the thrust vector, as shown 
in Figure 15. The data ranges from 0.0 in the rearward position to 1.0 in the forward 
position. This data is multiplied by a constant representing the maximum amount of thrust 
can be achieved, as shown in the following equation: 

hrust setting = (raw throttle * 40,000) - ( forward speed * 111.1) (Eq. 9) 
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Figure 15: Throttle Data Flow 


By multiplying the raw throttle data by 40,000, the maximum thrust 
available, the thrust produced is then a percentage of the maximum. For example, having 
the throttle at the halfway position results in raw throttle data of 0.5. After multiplying this 
by the maximum thrust available, the thrust produced is 20,000 pounds. 

The additional adjustment made to the thrust setting, shown in Eq. 9, 
reduces the amount of thrust produced as airspeed increases. This is done to simulate 
maximum forward airspeed in level flight. The SH-60B can achieve about 180 m.p.h. in 
normal level flight. To simulate maximum forward airspeed in level flight, the thrust 
produced by the helicopter must equal the weight at the maximum airspeed. This condition 
will result in the helicopter being flown at maximum speed with maximum power applied 
while maintaining its current altitude. If the pilot flies the helicopter any faster by pushing 
the joystick forward to pitch the nose down, the resultant thrust produced will decrease to 
less than 20,000 pounds. Therefore, the helicopter will descend. Also, since the throttle is 
already at maximum, a climb cannot be initiated by adding power to produce more thrust. 
The only way to climb in this situation is to pull back on the joystick thereby pitching the 
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helicopter’s nose up. The helicopter will climb from its increase in angle of attack to the 
oncoming airflow, but airspeed will also decrease. 

To reduce the thrust produced at maximum forward airspeed to a point 
where it equals the weight of the helicopter, a constant factor, when multiplied by the 
airspeed, is subtracted from the thrust calculation resulting from the throttle position. This 
is shown in Eq. 9. The constant 111.1 produces this result. It is calculated from the 
following equation: 


helicopter weight (lbs) 


(Eq. 10) 


“ maximum forward speed (mph) 

This constant affects flight at any airspeed, not just flight at maximum 
forward level flight airspeed. The effect this calculation has on helicopter control is that as 
it flies at a faster airspeed, more power is required to maintain altitude. This adds realism 
to the simulation of the helicopter as well as limit the forward speed in level flight. 


2. Vector Calculations 

Once the magnitudes of the forward speed, lateral speed and thrust vectors in Figure 
11 have been calculated based on control inputs, their directions need to be calculated. This 
is accomplished using the heading, pitch and roll angle calculations and the Performer 
function pfMakeEulerMat(). This function takes the heading, pitch and roll angles and 
transforms them into a 4-by-4 matrix representing the amount of rotation in world 
coordinates about an object’s x, y and z axes [HART94]. 

Once the matrix is formed, another Performer function, pfKformPt3(), is used to 
transform the matrix into the forward velocity, lateral velocity, and total lift vectors, shown 
in Figure 16. This function transforms a vector expressed in the object’s coordinate system 
into a vector expressed in world coordinates [HART94]. It is used here to transform the x, 
y and z axes in the helicopter’s coordinate system to the same axes expressed in world 
coordinates. The helicopter’s x axis is the lateral velocity vector, its y axis is the forward 
velocity vector, and its z axis is the thrust vector. 
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Figure 16: Total Velocity Vector 


The next step is to normalize these vectors using the Performer function 
pfNormalizeVec3(). This function scales a vector to unit length [HART94]. It is used here 
to make the forward velocity, lateral velocity, and thrust vectors a uniform length to then 
scale them to the desired magnitudes as previously calculated. 
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Next, each vector is scaled to its respective magnitude, shown in Figure 16, using 
the pfScaleVec3() Performer function. The thrust vector is scaled to the thrust setting, the 
forward velocity vector is scaled to the forward speed, and the lateral velocity vector is 
scaled to lateral speed. These vectors now represent their respective vectors in Figure 11. 

3. Weight Vector 

The fourth vector in Figure 11 is the weight vector. This vector always points down 
from the center of the helicopter in the negative z axis of the world coordinate system. This 
is accomplished by using pfScaleVec3() to scale the world’s z axis vector of unit length, 
which is the vector <0,0, -1>, to the constant representing the helicopter’s weight, which 
is set to 20,000 pounds. Since this vector always points to the ground, it is not transformed 
from the 4-by-4 Euler matrix. 

4. Velocity 

The final step in calculating the helicopter’s motion is to calculate the velocity 
vector. This is done by adding the thrust, weight, forward velocity and lateral velocity 
vectors to obtain the total speed and direction of the helicopter. 

The first step here is to use the Performer function pfAddVec3() to add the forward 
velocity and lateral velocity vectors into a temporary vector. This represents the velocity in 
the helicopter’s x-y plane and is later added to the thrust and weight vectors to obtain total 
velocity 

This same function is used to add the thrust and weight vectors. The result 
represents the total force produced by the main rotor. This resultant vector, labeled total lift, 
determines whether the helicopter climbs or descends. Since the helicopter’s pitch and roll 
angles determine the direction of the total lift vector, as shown in Figure 3, its vertical 
component (effective lift), must counteract the helicopter’s weight. If the effective lift is 
greater than the helicopter’s weight, it will climb; if it is less than the weight, the helicopter 
descends. If they are the same, the helicopter will maintain its altitude. 
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The next step is to scale the total lift vector just calculated using pfScaleVec3(). The 
total lift vector represents the force produced by the helicopter’s main rotor. To translate 
force into acceleration, Eq. 1 is used. To translate the total lift vector into acceleration, it 
must be scaled by the inverse of the helicopter’s mass, a constant defined at compile time. 
This has the effect of shortening the total lift vector without changing its direction. This 
resultant vector is scaled again with pfScaleVec3( j by A time, the elapsed time between the 
last display frame and the current one, to change acceleration into velocity. The total lift 
vector now represents the motion of the helicopter resulting from the lift produced by the 
helicopter to counteract its weight. 

Finally, the temporary vector representing the helicopter’s x-y plane velocity and 
the total lift vectors are added using pfAddVec3(). This velocity is then used to calculate the 
helicopter’s position in the world coordinate system for the next display frame. 

To make the helicopter easier to fly, limits were programmed into this system to 
prevent the helicopter from flying to fast sideways or backwards. An SH-60B is limited to 
flying at about 40 m.p.h. in sideways or rearward flight [NTPS90]. The reason for this limit 
is to prevent damage to the helicopter resulting from extreme aerodynamic situations. The 
programmed limit is therefore 40 m.p.h. for both sideways and rearward flight. Limiting 
the program makes the simulated helicopter easier to control for inexperienced users and 
prevents flight in unusual aerodynamic situations, which are beyond the scope of this 
research. 

5. Ground Motion 

The main difference between calculation of motion when the helicopter is on the 
ground versus when it is in the air is that there can be no sideways motion. This is due to 
the helicopter’s landing gear, which only allows it to travel forwards and backwards. As a 
result, no lateral speed need to be calculated. 

As for the forward motion calculations, the aerodynamics that apply to a helicopter 
in flight also apply to one operating on the ground. Forward motion is caused by creating 





enough effective thrust, shown in Figure 3, to overcome the drag caused by the contact of 
the landing gear with the ground. To move forward then, power must be added and forward 
pitch must be applied. 

Real helicopters have brakes to slow down and stop while on the ground. However, 
since the rudder pedal controls utilized for this research have no brakes equivalent, the 
effect must be simulated through other means. This was accomplished by programming 
pitch inputs from the joystick to control acceleration. To slow down or stop, the joystick 
must be pulled back and the throttle increased. 

Heading control on the ground is the same as it is in the air, and that is by tail rotor 
control through rudder pedal input. Helicopter’s do not have directly steerable wheels like 
automobiles do. Instead, the force produced by the tail rotor is quite sufficient to change the 
helicopter’s heading since the torque produced by the main rotor, described in Chapter III, 
is still present. For this reason, the raw data from the rudder control pedals controls heading 
on the ground just as it does in a hover. 

To protect the landing gear from damage, real helicopters are restricted from going 
above certain speeds while on the ground. The ground speed limit for the SH-60B is about 
45 m.p.h., which is also the programmed limit for speed on the ground [NTPS90]. This 
gives the user adequate control and realism without subjecting the helicopter to extreme 
situations. These kinds of situations can cause serious damage to helicopters, and 
simulating this is beyond the scope of this research. 

In addition, moving backwards on the ground is not permitted. Although most 
helicopters can taxi backwards easily, it is not practiced. There are two reasons for this. The 
first reason is that since helicopters don’t have rear windshields like automobiles do, it is 
impossible for the pilot to see behind the helicopter to prevent colliding with anything. 
Secondly, to taxi backwards, the pilot must pull back on the cyclic and add power from the 
collective. Since doing this causes the main rotor system to pitch back, the possibility exists 
for the main rotor blades to impact the rear portion of the fuselage. 



If the pilot flying this simulated helicopter lands while moving faster than the 
maximum forward ground limit or backwards, the helicopter is programmed to speed up or 
slow down gradually until ground speed is within limits. Flight can be achieved again, 
however, before the speed is in limits. 

C. SUMMARY 

The purpose of this portion of this research was to give helicopters in NPSNET the 
same controllability that real helicopters have. Due to the aerodynamic complexity of real 
helicopters, though, a completely physically based model was neither attempted nor 
desired. The purpose here is twofold. First, NPSNET must still be used by anyone, 
including those with no helicopter piloting experience, while giving the user some idea of 
what it takes to fly a real helicopter. The previous method of helicopter control gave users 
adequate control of a hehcopter, but sacrificed too much realism to be a useful indicator of 
helicopter flight. 

The second purpose behind this design is to execute realistic control of the 
helicopter without requiring special hardware to make complex calculations. Since 
NPSNET is designed to run on commercial off-the-shelf computer systems, the blade 
element method to calculate helicopter aerodynamics is too computationally expensive to 
be useful in NPSNET. The simpler balance of forces method provides enough realism to 
the simulation without sacrificing speed or usability. 
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VI. INTERFACE FOR MULTIPLE WORKSTATION ASW 


A. INTERFACE PANEL DESIGN 

As mentioned in Chapter II, the Panel interface designed by Chris McMahan 
provides a useful starting point to implement an ASW interface. This chapter describes the 
shortcomings of the original system and the changes made to the system for this research 
to provide ASW functionality. 

B. COMMUNICATION WITH NPSNET 

1. Original Implementation 

Communications between the interface Panel and a workstation running NPSNET 
in remote mode are conducted through a single socket structure. This structure, called a 
GU1_MSG_DATA packet, is shown in Figure 18. This packet is used to pass control and 
weapons information between NPSNET and the Panel across the network. 

The proper use of this packet is shown in Figure 19. In this case, one Panel is being 
used in conjunction with one workstation running NPSNET in remote mode. Remote mode 
means that the Panel displays velocity and position information about the NPSNET vehicle, 
herein called the host vehicle, and can be used to control that vehicle. This mode is turned 
on when NPSNET is initialized with the “-r” command line switch. This allows NPSNET 
and the Panel to communicate by passing the GUI_MSG_DATA packet over the network. 
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art type; 
art length; 


// throttle data required to read the throttle position (-1.0 to 1.0) and to 
// set the throttle input with the scale widget 
float throttlesetting; 

// joystick data required to read the joystick position and set input as required 
// (each is between -1.0 and 1.0) 

float joystickX; 
float joystickY; 

// vehicle settings read from NPSNET only (not sent from interface) 
float positionX; 
float positionY; 



float gunAzimuth; 
float gunElevation; 


EntitylD vehiclelD; 

// flag settings to execute NPSNET actions 
EntitylD targetVehiclelD, 

BYTE attachMode; // including tether, attach, target,teleport 

BYTE weaponsMode; // indudihg primary, secondary .tertiary, targetingEnable 

BYTE hudMode; // including hudEnable 

BYTE environmentMode; // including fogEnable, wireframeEnable, textureEnabie, 


// variable settings to control NPSNET functions 
BYTEfogSetting; 

BYTE hudSetting; 

//NEW - data passed to NPSNET about FTP use and position 
int FTPon; 
float FTPXposit; 
float FTPYposit; 

} GULMSG_DATA; 

Figure 18: GUI_MSG_DATA structure 
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Figure 19: Single Panel/Single NPSNET 
Cooperation 

The use of this method fails when more than one workstation is running NPSNET 
in remote mode, as shown in Figure 20. In this example. Workstations #2 and #3, each 
running NPSNET in remote mode, both communicate to the Panel application through the 
passing of GUI_MSG_DATA packets over the network. The Panel becomes unusable 
since conflicting information is received from different NPSNET host vehicles. In addition, 
if the Panel sends controlling information to NPSNET, it is possible for the host vehicles 
being simulated on Workstations #2 and #3 to be controlled by the one Panel on 
Workstation #1. This is generally not a realistic scenario: one person cannot drive two 
separate vehicles. 

The situation becomes even more confusing when there are multiple interface 
Panels and multiple workstations tunning NPSNET in remote mode, as in Figure 21. Each 
panel could control both NPSNET host vehicles, and each Panel receives conflicting 
GUI_MSG_DATA information from both host vehicles. 
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Figure 21: Multiple PanelMultiple NPSNET 
Problem 
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Exclusive Two-way Communication with NPSNET 


As described in Chapters IE and IV, helicopter ASW is conducted through the 
utilization of each member of the helicopter’s crew. Each crewmember performs specific 
functions while supplementing the duties of fellow crewmembers. 

The functionality of the interface Panel provides an adequate framework to model 
helicopter ASW. However, to model the crew coordination concept, it is necessary that one 
Panel communicate with one NPSNET host vehicle, regardless of how many workstations 
are running NPSNET in remote mode. 

The approach taken to accomplish this was to have one NPSNET workstation 
running in remote mode cooperate with one Panel, as shown in Figure 22. Each workstation 
supplies address information to the GUI_MSG_DATA packets it generates. When either 
workstation receives the packets, it compares the address information in the packet to the 
address information stored in the program about which workstation it is cooperating with. 
If the addresses match, the state of the respective program is updated. Otherwise, the 
GUI_MSG_DATA packets are discarded. 



Figure 22: Desired Multiple Panel/Multiple 
NPSNET Cooperation 
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a. Communication from the Interface Panel to NPSNET 

The first step to accomplish this was to change how the interface panel is 
initialized so that a specific workstation could be designated as the cooperative 
workstation. This designated workstation will run NPSNET in remote mode, and it is the 
only workstation which the Panel will communicate with. A new command line 
initialization switch was implemented to supply the necessary workstation identification 
information to the Panel at start-up. 

To initialize the Panel in this mode, the new switch uses the character ‘s’ to 
designate a session. The syntax of the switch is “-s <workstation name>”. When the name 
of a valid workstation is supplied, the identification information allows both NPSNET and 
the Panel to filter out unwanted GUI_MSG_DATA packets from other workstations. The 
workstation name is read from the command line at initialization and then verified in the 
datafiles/hosts.dat file, an example of which is shown in Figure 23. The two pieces of 
applicable information are the second and third fields of the file, indicating the site number 
(all 36 in the example) and the host number (the number following 36). This information is 
stored in the variable “npsnetAddress.address.site” and “npsnetAddress.address.host”, 
respectively, as part of the GLOBAL_DATA structure defined in global.h. 

After initialization of the Panel in complete, it can now communicate with 
the desired workstation mnning NPSNET in remote mode by passing the 
GUI_MSG_DATA packet. When a change is made to the Panel’s state that requires a 
similar change of state in NPSNET, the applicable data is sent to the Message class of the 
Panel [MCMA95]. The Message class then generates a GULMSG_DATA packet, writing 
the applicable information to the appropriate field of the packet. The last step performed by 
the Message class is to write the “npsnetAddress.address” data field to the “vehiclelD” field 
of the GUI_MSG_DATA packet and write the packet to the network. This is performed in 
Message::writeSocket(), seen in Appendix B begiiming on line 5. 
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bessie 36 1 ecO 

betsie 36 2 ecO 

black 36 3 ecO 

bond 36 4 ecO 

bossie 36 5 ecO 

bradley 36 6 ecO 

Clancy 36 7 ecO 

clarabell 36 8 ecO 
cool 36 9 ecO 

daisy 36 10 ecO 

dude 36 11 ecO 

elsie 36 12 ecO 

elvis 36 13 etO 

fletch 36 14 ecO 

gnarly 36 15 ecO 

grant 36 16 ecO 

gravyi 36 17 ecO 
gravy2 36 18 ecO 
gravy3 36 19 etO 
gravyS 36 20 etO 
holmes 36 21 ecO 
like 36 22 ecO 
meatloaf 36 23 etO 
medusa 36 24 ecO 
minotaur 36 25 ecO 
patton 36 26 ecO 

pershing 36 27 ecO 
rambo 36 28 ecO 
ridgeway 36 29 ecO 
totally 36 30 ecO 

trouble 36 31 ecO 

turing 36 32 ecO 

chaos 36 33 ecO 
federation.arl.mil 36 34 etO 
orion.arl.mil 36 35 etO 
hred-iport3.arl.mil 36 36et0 
hred-iport2.arl.mil 36 37 ecO 


Figure 23: Example hosts.dat File 


When any NPSNET workstation running in remote mode receives this 
packet, it first compares the “vehicIelD” field in the packet with its own identification 
information, which is obtained from the same hosts.dat file used by the Panel. This is 
performed in the main application loop of NPSNET in the source file main.cc, shown in 
Appendix A beginning on line 9. If there is a GUI_MSG_DATA packet available to be 
read, and if the “vehiclelD.address” field of the packet matches the workstation’s own 
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“DIS_address”, the rest of the information in the packet is assigned to the appropriate place 
to update the NPSNET host vehicle’s state. If the GUI_MSG_DATA “vehiclelD.address” 
field does not match the workstation’s own address information, the packet is discarded. 

The situation described here is initiated when the Panel has remote control 
of the NPSNET host vehicle and any control input changes are made. This includes 
weapons fire information and the newly implemented Fly-to-Point data, both described 
later in this chapter. This filtering of GUI_MSG_DATA packets now allows one Panel to 
cooperate with a host vehicle being simulated on one workstation, while other Panels 
communicate with their own NPSNET host vehicles. This operates as shown in Figure 22. 
b. Communication from NPSNET to the Interface Panel 
The previous section described the situation where the interface Panel sends 
control information to NPSNET running in remote mode. NPSNET also sends the 
GUI_MSG_DATA packet to the Panel when the host vehicle changes its state. This is 
necessary when the host vehicle changes any data that gets repeated on the Panel’s display, 
including heading, pitch, roll, position, velocity, and altitude. 

To maintain the capability shown in Figure 22, the Panel must also filter out 
any GUI_MSG_DATA packets it receives from unwanted NPSNET workstations running 
in remote mode. This is done in a similar manner as when the Panel generates the packets 
for NPSNET, with the exception that NPSNET puts its own address information into the 
packet’s “vehiclelD.address” field. 

In each cycle of NPSNET’s main application loop, every field of the 
GUI_MSG_DATA packet that involves control data is updated with the host vehicle’s 
appropriate information, shown in Appendix A starting on line 82. As can be seen on lines 
94 an 95, the workstation’s own address information is written to the “vehiclelD.address” 
field of the GUI_MSG_DATA packet. After five cycles of the main application loop, the 
latest packet to be updated is sent to the network. 
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When the Panel receives a GUI_MSG_D ATA packet from NPSNET, it first 
compares the “vehiclelD.address” field of the packet with the “nspnetAddress.address” 
variable assigned upon initialization and mentioned in the previous section. This is shown 
in the readSocketf) function beginning on line 26 of Appendix B. If the address information 
matches, the packet was sent from the cooperating workstation that was designated with the 
“-s” switch. Therefore, the packet is sent to the appropriate Panel classes to update any 
displayed data, just as had been done in the Panel’s original implementation [MCMA95]. 
However, if the addresses differ, the packet is discarded and the Panel’s display is not 
updated. 

With this, the two-way exclusive communication that was the goal of this 
research and illustrated in Figure 22 has been achieved. Both NPSNET and the Panel get 
updated by receipt of GUI_MSG_DATA packets addressed to or from the desired 
workstation while all others are discarded. 

C. GUI_MSG_DATA PACKET UTILIZATION FOR ASW 

Two of the duties listed in Chapter IV required by the ATO in an ASW helicopter 
are to navigate to target areas for employment of sensors and weapons, and to direct 
sonobuoy and weapon delivery. These duties require communication between the pilot, 
who is flying the helicopter, and the ATO. This crew coordination must be conducted 
efficiently to adequately prosecute a submarine threat. 

With the two-way exclusive communication implemented between the interface 
Panel and NPSNET, the crew coordination concept can now be modelled. By incorporating 
navigation and ASW weapons delivery functionality into the Panel, the functions 
performed by the ATO are simulated. The data generated by the ATO is transmitted to the 
selected NPSNET workstation operating in remote mode to simulate crew coordination. 
Host vehicle data is also transmitted from the pilot’s workstation back to the ATO’s Panel 
so the ATO can back up the pilot in maintaining safety of flight. All of this is performed 
through the use of the GUI_MSG_DATA packet. 
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1. Fly-to-Point Navigation 

The way the ATO informs the pilot where to fly the helicopter is through the use of 
fly-to-points (FTP). During an ASW mission, the ATO decides where to deploy sonobuoys 
and launch weapons. The location he decides on is a precise location based on the tactics 
used to prosecute the submarine. The ATO enters FTP information onto his tactical display 
as a prioritized list of locations. The highest priority FTP is the one the pilot will fly to next. 

The information regarding this FTP is displayed to the pilot as a heading cursor on 
his compass. The pilot turns the helicopter until its heading and the heading to the cursor 
are the same. Once the helicopter reaches this FTP, the point disappears, which is called 
capturing the FFP. The ATO can then launch a sonobuoy or weapons as he desires. The 
pilot also gets information about the FTP with the next highest priority after capturing the 
current one. 

To model this functionality, the ability of the ATO to designate FTP’s on the Panel 
and communicate their location to the pilot’s NPSNET workstation was implemented. This 
is shown in Figure 24. The left side of the figure shows the radar display of the Panel, which 
is used as the ATO’s tactical display. It shows the helicopter in the center, with a line from 
its center pointing down and to the left to indicate the helicopter’s heading. The two 
triangles are FTP’s, with the one below the helicopter having highest priority and the one 
above having a lower priority. The right side of the figure shows the compass on the heads- 
up display (HUD) for this same helicopter in NPSNET. The next to the ‘S’ indicates to 
the pilot which way to head to capture the FTP, in this case, to turn left from heading 234. 
How the ATO enters FTP information onto the display is shown in the next chapter. 

When the ATO enters an FTP onto the Panel’s radar, the function 
Message::FTPChanged() is called, which generates a GUI_MSG_DATA packet to notify 
the pilot where to go. The FTP location information is written in world coordinates to the 
“FTPxposit” and “FTPyposit” fields of the GUI_MSG_DATA packet, seen at the bottom 
of Figure 18. The packet is then sent to NPSNET over the network as described earlier. 
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a) Panel radar display 


b)NPSNET HUD display 


Figure 24: Conununication of FTP 
Information 

When the pilot’s NPSNET workstation receives the packet, the FTP position data 
is written to the FTP data fields of the PASS_DATA structure defined in draw.h in the 
source code of NPSNET. This assignment is shown on lines 39 through 41 in Appendix A. 
This data is then used by the vehicle_hud_draw() function in NPSNET’s vehicle.cc to 
display the heading cursor on the pilot’s compass. This data is displayed until the FTP is 
captured or the ATO deletes this FTP or designates a new one on the radar display of the 
Panel. 


2. Weapons Delivery 

Once the ATO has communicated to the pilot where to fly the helicopter, it is up to 
the ATO to launch weapons and sonobuoys, as described earlier. Since weapons in 
NPSNET are themselves entities, generation of the weapon is handled by the vehicle’s 
workstation, which sends DIS entity state, fire, and detonation PDU’s regarding the 
weapon to the other vehicle’s participating in the simulation. 





To model this capability, use of the GUI_MSG_DATA packet is again needed. 
When the ATO generates a torpedo or missile launch from the weapons buttons on the 
Panel, shown in Figure 17, a GUI_MSG_DATA packet is generated by calling the weapon 
launch functions of the Message class. These are shown in Appendix B beginning on line 
155. The data sent to NPSNET is in the form of a byte called “weaponsMode” in the 
GUI_MSG_DATA packet, as seen in Figure 18. It specifies whether to launch the vehicle’s 
primary, secondary or tertiary weapon. The packet is then sent onto the network. 

When the NPSNET workstation meant to get the packet receives it, the 
“weaponsMode” byte value is stored in a variable called “the_button”, seen on line 21 of 
Appendix A. If the vehicle type is an ASW helicopter, then “the_button” is compared with 
constants defining primary, secondary, or tertiary weapons. Whichever value matches, a 
firebuttonhitO function call is made to the Munitions class in NPSNET, and the appropriate 
weapon is fired just as if the person at the flight controls launched it. 

Since the ATO generally launches the torpedoes or missiles in an SH-60B 
helicopter, the capability was given to have the ATO running the Panel be able to launch 
weapons even if the pilot operating the vehicle in NPSNET has flight control over the host 
vehicle. This simulates additional crew coordination functionality between the pilot and 
ATO. The pilot also still has the ability to launch weapons from buttons on the flight 
controls or from the keyboard. 

D. SUMMARY 

The communications conducted between the interface Panel and NPSNET prior to 
this research contained adequate framework to simulate crew coordination. By 
programming both the Panel and NPSNET to filter out unwanted GUI_MSG_DATA 
packets, a single Panel can now communicate with a single NPSNET entity while other 
Panels operate in conjunction with their entities. These crew coordination concepts are 
shown through the added capability of passing FTP data from the Panel to the NPSNET 
entity, and through the flight data passed from the entity to the Panel for display. 
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VII. ASW SYSTEM DESCRIPTION 


A. INTRODUCTION 

This chapter describes the ASW functionality added to NPSNET and the interface 
Panel, including a description of the radar display, how to enter and manipulate Fly-to- 
Points (FTP), how sonobuoys are modelled, and how to launch torpedoes and missiles. The 
ASW functionality is available only when NPSNET and the interface Panel are initiated in 
the correct mode. NPSNET must be initialized as an SH-60B helicopter in remote mode as 
the host vehicle. This is accomplished by including the “-v” command line switch with 
“sh60” as its argument. Remote mode is turned on by including the “-r” switch at 
initialization, which allows NPSNET to send and receive GUI_MSG_DATA packets. 

To activate the ASW functionality in the interface Panel, it must be initialized in 
session mode with the “-s” command line switch with the name of the host vehicle’s 
workstation as its argument, as described in Chapter VI. For example, if we want to control 
the NPSNET host vehicle on the workstation “elvis”, initialized as described above, then 
the Panel must be initialized from another workstation with the argument “-s elvis”. This 
allows the Panel to send and receive GUI_MSG_DATA packets, and enables packet 
filtering for both NPSNET and the Panel, also described in Chapter VI. Other ASW 
functionality is activated by selecting “ASW Helo” from the Vehicle menu of the Panel. 
This enables FTP and sonobuoy functionality. Figure 17 shows the Panel in ASW 
Helicopter mode. 

B. PANEL RADAR DISPLAY 

The ATO in an SH-60B has a tactical display used for viewing sensor data, 
managing sonobuoys, entering FTP’s, and controlling the tactical conduct of a mission. 
This display, shown in Figure 6, is graphical in nature, giving the ATO a picture of the 
ASW situation. 
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The SH-60B tactical display is simulated in this research through the use of the 
radar display on the interface Panel. The basic functionality from the original 
implementation of the Panel remains largely unchanged [MCMA95]. Its function is to 
display the location of entities in the virtual environment relative to the host vehicle’s 
location. The center of the radar display represents the location of the host vehicle. All other 
entities, whose locations are determined from DIS Entity State PDU’s received from the 
network, are shown on the radar as icons representing the vehicles’ t5fpe. 

One significant change made to the radar display of the Panel was its orientation. 
Originally, the heading of the host vehicle determined the radar’s orientation, with the 
vehicle’s heading pointing up. So, the radar picture rotated as the host vehicle turned. This 
was an unrealistic depiction of a radar’s display, and can get confusing for the user. Real 
radar displays are oriented such that north points up on the radar’s display. When the 
vehicle turns, the display stays oriented towards north and the iconic representation of the 
vehicle turns. The icon indicates the heading of the helicopter with a small line inside of the 
icon. 

To simulate this, the rotating functionality of the Panel’s radar display was 
removed. As a result, north points up on the display regardless of vehicle heading. To 
indicate the host vehicle’s heading, a small line is drawn from the center of the radar 
pointing in the direction of the host vehicle’s heading. This can be seen in Figure 25, which 
shows that the host vehicle’s heading is about southwest. 

Additional functionality was added to the Panel’s radar display to allow for the 
display and management of FTP’s and sonobuoys. The source code for the Radar class of 
the interface Panel is contained in Appendix C and Appendix D. 

1. Fly-to-Point Management 

FTP’s are navigational aids used by the ATO to teH the pilot where to fly the 
helicopter. They are used in ASW to indicate locations for sonobuoy and weapons 
deployment. 
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Figure 25: FTP Example 

In the interface Panel, FTP’s are entered and displayed in the radar display, as 
shown in Figure 25. Each FTP is displayed as a triangle with a number inside indicating its 
priority. Up to six FTP’s can be entered on the radar display. Source code for displaying, 
entering, deleting, and capturing FTP’s is contained in Appendix C and Appendix D. 
a. Entering FTP’s 

Entering FTP’s onto the radar display is made possible by turning on the 
FTP toggle button, as shown in Figure 17. New FTP’s appear on the radar display at the 
mouse pointer’s position when the left mouse button is pressed in the radar’s display area. 
If there are a maximum number of FTP’s in the system, in this case six, no more can be 
entered until one of the existing FTP’s has been deleted or captured. 
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As mentioned earlier, each FTP also has an associated priority, which 
indicates the order in which the FTP’s should be flown to. Newly entered FTP’s have the 
lowest priority of those in the system. For example, if there are three FTP’s currently 
entered into the system, the next FTP will have priority 4, assuming that none of the original 
FTP’s gets deleted from the system before the new one is entered. If there are no FTP’s 
currently in the system, the new FTP will have priority 1. 

The significance of the highest priority FTP (priority 1) is that it is the 
position selected by the ATO for the next sonobuoy or weapon launch. As such, it is the 
only FTP whose position is transmitted to the host vehicle, which is described in Chapter 
VI. 

b. Capturing FTP’s 

When the helicopter gets within a certain distance of the highest priority 
FTP, it is deleted from the system, signifying that the position the ATO wanted the pilot to 
fly to has been reached. This distance is calculated as a horizontal distance since FTP’s are 
not based on altitude. The maximum distance this can occur is defined at compile time to 
be 500 yards. Hence, when the helicopter gets within 500 yards of the priority 1 FTP, it is 
captured. Only the priority 1 FTP can be captured. 

After capturing the priority 1 FTP, the priorities of any other FTP’s in the 
system are increase by one. So, if the priority 1 FTP in Figure 25 is captured, it is removed 
from the radar display, and the priority of the priority 2 FTP becomes priority 1, whose 
location is then transmitted to the NPSNET host vehicle. In addition, if there are six FTP’s 
in the system prior to one being deleted or captured, then there are five FTP’s after. In this 
case, another FTP can then be added to the system, as described earlier. 

As stated before, FTP’s denote the locations where the ATO wishes to drop 
sonobuoys or torpedoes. One of the capabilities of the SH-60B is that it can automatically 
launch sonobuoys upon the capture of an FTP. To simulate this, the Panel automatically 
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inserts a sonobuoy into the sys 
in this chapter. 


when capturing an FTP. Sonobuoy use is described latei 


c. Deleting FTP’s 

Occasionally, the ATO may wish to delete an FTP from the system. This is 
done when the ATO wishes to reprioritize them, change their locations, or insert new ones 
if the maximum number is already in the system. 

Deleting FFP’s is accomplished on the Panel by first turning the FTP toggle 
button off. Then, by placing the mouse pointer on a currently existing FTP and clicking the 
left mouse button, the FTP disappears from the radar display. In addition, remaining FFP’s 
are reprioritized, if necessary, so that the priorities of all FTP’s in the system is an 
increasing sequence (i.e. no priority gaps). This is shown in Figure 26. On the left side, 
there are four FTP’s with priorities 1 though 4. When the FTP with priority 2 is deleted, the 
rest of the FTP’s get renumbered such that the FTP with priority 3 now has priority 2, and 
the FTP with priority 4 now has priority 3. 

2. Sonobuoy Usage 

As described in Chapter V, sonobuoys are used to track subsurface contacts. For 
this research, sonobuoys are modelled only as part of the interface Panel. The reason for 
this is that, as a sensor, the sonobuoy would need to be modelled as a sensor entity in 
NPSNET to provide the necessary information to other vehicles in NPSNET regarding its 
characteristics. This would necessitate the use of the DIS Emission PDU, currently 
unimplemented in NPSNET. 
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a) before deleting FTP b) #2 FTP deleted 


Figure 26: Deleting FTP’s 

To model sonobuoys through the Panel, the weapons launch buttons and the radar 
display are again used. This allows for entering sonobuoys into the system, displaying 
sonobuoy locations, and displaying subsurface contact information. Sonobuoys are 
displayed as a circle around the letter ‘S’ with a line indicating the submarine’s position, as 
shown in Figure 27. 

a. Entering Sonobuoys 

Sonobuoys can be entered in to the system automatically or manually. Since 
sonobuoys are launched from the helicopter’s current location, sonobuoys first appear in 
that location. The sonobuoy remains in that location for the duration of the simulation. 

To automatically enter a sonobuoy into the system, the helicopter must 
capture a FTP, as described earlier. Manually launching sonobuoys is accomplished by 
pressing the sonobuoy button next to the radar display. A maximum of 25 sonobuoys can 
be entered into the system. There is no difference in the functionality of manually launched 
sonobuoys versus those automatically launched. 
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Figure 27: Sonobuoy Examples 


b. Sonobuoy Contact Information 

The type of sonobuoy modelled in the interface Panel is an active sonobuoy. 
As described in Chapter IV, active sonobuoys reveal bearing and distance information from 
the sonobuoy to the subsurface contact by transmitting a sonar signal and receiving the 
sonar echo. Due to their limited power, both active and passive sonobuoys are generally 
considered short range sensors for tracking submarines. 

Sonobuoys simulated in the Panel do not detect subsurface contacts by 
listening for acoustic signals. This is because entities in NPSNET transmit DIS Entity State 
PDU’s, which have no acoustic information. The Panel, however, receives these PDU’s to 
be able to display these entities on the radar display. By extracting vehicle type and position 
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information from the PDU’s, the Panel system knows the location of all vehicles in the 
simulation, including submarines. 

To display the location of a submarine relative to a sonobuoy, the distance 
from the sonobuoy to the submarine is tested. To simulate the limited range of sonobuoys, 
the location of a submarine is displayed only if its distance is less than 1000 yards. If it is, 
a line segment is drawn from the sonobuoy to the submarine’s location. If the distance is 
greater than 1000 yards, no line segment is drawn. Both of these situations are shown in 
Figure 27, where the top sonobuoy is in contact with the submarine, but the bottom one is 
not. In addition, the iconic representation of the submarine is not shown. This is omitted to 
simulate a radar’s inability to detect subsurface vehicles and to offer the greater challenge 
of locating the submarine without knowing any position information when the simulation 
is begun. 

Multiple sonobuoys can indicate contact with a single submarine. If one 
submarine is within 1000 yards of two or more sonobuoys, lines are drawn from each 
sonobuoy to the submarine, as shown in Figure 28. If there is more than one submarine 
within range of a sonobuoy, only the position of the closest submarine is indicated on the 
radar display. 

3. Weapons Launch 

Weapons can be launched in NPSNBT either by the person controlling the host 
vehicle in NPSNET or by the person operating the interface Panel. To launch weapons in 
NPSNET, the pilot can either press the appropriate button on the joystick, or press the 
appropriate button on the keyboard. This functionality was not changed for this research. 

Changes were made to weapons launch functionality in the interface Panel, 
however. To launch weapons from the Panel, the buttons labelled ‘Torpedo” and “Missile”, 
shown in Figure 17, are used. At any point in the simulation exercise, the person operating 
the Panel places the mouse pointer on the appropriate weapon button and presses the left 
mouse button. This sends a GUI_MSG_DATA packet to the NPSNET host vehicle, which 
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launches the selected weapon. Since the ATO has the responsibility of launching weapons 
in the SH-60B, the Panel can be used to launch weapons regardless of who has control of 
the host vehicle in NPSNET, either the person flying the NPSNET helicopter or the person 
controlling the Panel. 

C. WEAPONS SIMULATION 

The SH-60B has the capability to carry and launch Penguin missiles and Mk 48 or 
Mk 50 torpedoes. This is simulated in a general sense in NPSNET. The SH-60B in 
NPSNET has two weapons, a missile and a torpedo. The missile, representing the Penguin, 
is a generic missile that can home in on a targeted vehicle. No functionality was added to 
the current simulation of missiles in NPSNET in this research. 

To simulate torpedoes, a new munitions class was added to NPSNET to represent 
helicopter launched torpedoes. What is unique about this kind of weapon in NPSNET is 
that is has two separate trajectory calculations, one for the airborne ballistic phase, and one 
for the underwater homing phase. In addition, the torpedo only has the capability to home 
in on and destroy ships and submarines in NPSNET. 

When a torpedo is launched, an array is created containing the identification 
numbers of vehicle in the current simulation that are eligible to be targeted, which are ships 
and submarines. This is done to allow a quick lookup for the torpedo when trying to gain a 
contact to start homing in on the target. The torpedo itself follows a ballistic trajectory until 
water impact. 

Once the torpedo impacts the water, the homing phase begins. If there are any 
eligible targets in the simulation, the distance from the water impact point to the vehicle is 
calculated. If any of these vehicles are within the torpedo’s acquisition range, defined at 
compile time to be 3000 yards, the closest of these vehicles becomes the target. The torpedo 
then turns toward the target. If there are no eligible vehicles in range, the current distance 
from the torpedo to the eligible vehicles is checked on each display loop in case a vehicle 
enters the torpedo’s acquisition range before the end of its run. If no vehicles are acquired. 
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Figure 28: Multiple Sonobuoy Contact 


the torpedo continues on it current heading, maintaining its last calculated pitch and roll 
angles. 

In addition to homing toward the closest ship or submarine, calculation of the 
distance the torpedo has travelled since water impact is made on each display loop. This is 
done to limit the range of the torpedo. If it has run for 2000 yards underwater without hitting 
a target, the torpedo is deactivated. 

D. SUMMARY 

By adding ASW functionality to NPSNET and the interface Panel, crew 
coordination concepts as they apply to ASW can now be practiced in simulations over a 
network. The features added to simulate ASW, described in this chapter, provide to users 
the ability to prosecute subsurface entities in a realistic training environment. The interface 
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Panel, with the changes incorporated as a result of this research, now provides the 
functionality to realistically simulate the warfare area of ASW. 
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VIII. RESULTS, CONCLUSIONS, AND FUTURE RESEARCH 


A. RESULTS 

The result of this research is a simulation environment that incorporates real world 
concepts in ASW warfare. From the standpoint of the helicopter aircrew, realism was added 
to every aspect of the simulation to allow for a more useful training environment. 

The first step was to increase the realism for the pilot flying the ASW helicopter. A 
full set of flight controls was implemented to allow the pilot to have full control over the 
helicopter. The model of the helicopter was changed from a simple one vector 
representation to a more complex four vector representation. This model uses Performer to 
manipulate the vectors, so no speed is sacrificed with the increase in complexity of the 
model. This gives the helicopter the ability to hover, slide left or right, and fly backwards 
and forwards. The realism for the pilot is that he must maintain safety of flight by 
concentrating on his flying technique, letting the other members of the aircrew handle their 
own responsibilities. 

Next, the interface Panel was adjusted to add realism for the ATO. By having the 
Panel communicate with the host NPSNET vehicle through the GUI_MSG_DATA packet, 
the ATO can communicate to the pilot his intentions for the conduct of the mission. The 
pilot knows where he must fly, and once that point is reached, the ATO can deploy his 
sensors and weapons as necessary to prosecute the submarine. 

To allow for realistic joint training to occur, GUI_MSG_DATA packet filtering by 
both NPSNET and the Panel is used. This allows each Panel to communicate with its own 
NPSNET host vehicle. Several aircrews can prosecute submarines in a simulation, which 
is how real world helicopter ASW would be conducted. 
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B. 


CONCLUSIONS 


The objectives of this research were to design and construct an interface to simulate 
helicopter ASW and to increase the realism of helicopter control in NPSNET. The first 
objective was accomplished by adding ASW functionality to the interface Panel and 
NPSNET. The second objective was accomplished by redesigning the helicopter control 
model previously implemented in NPSNET. The functionality was developed and 
successfully incorporated into NPSNET and the interface Panel. The following conclusions 
have been reached. 

• Complex control models can be incorporated into NPSNET which provide a 
higher degree of realism for training pilots from a variety of airborne platforms. 

• Joint training and crew coordination concepts can be simulated through the use of 
a common interface panel representing a variety of vehicle types and warfare areas. 
Communication between the interface and the host vehicle can be isolated so that they 
communicate only with each other. 

• Simulation of specific warfare areas is possible by designing weapons and 
functions specific to the tactics used in that warfare area. Incorporating these into the 
simulation system allows for realistic warfare training. 

C. FUTURE RESEARCH 

This research provides a basic foundation for continued exploration of 
incorporating increased realism in NPSNET. The following is a list of topics for future 
research. 

• Continued development and refinement of physically-based vehicle control 
models in NPSNET. 

• Develop electromagnetic and acoustic sensor models and incorporate them into 
NPSNET. 

• Incorporate acoustic properties into ship and submarine models of NPSNET. 

• Further optimization of the network communications mechanisms to enhance 
speed and efficiency. 

• Design and implement a larger variety of warfare area specific functions for the 
Panel and NPSNET. 
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APPENDIX A. SOURCE CODE FOR NPSNET IN REMOTE 
MODE (MAIN.CC) 


1. #ifdef REMOTE.PANEL 

2. if ( G_static_data->remote_exists ) 

3. ( 

4. 

5. if (( G_reinote = socketjead ( &rstat)) != NULL ) 

6. { 

7. 

8. //NEW - Update the control settings only if the GUI_MSG_DATA is to us 

9. if (( G_dynamic_data->control == REMOTE ) && 

10. (G_remote->vehicleID.address.site == G_static_data->DlS_address.site) && 

11. (G_remote->vehicleID.address.host == G_static_data->DlS_address.host)) 

12. { 

13. the_thrust = G_remote->throttleSetting; 

14. theJoy_y = G_remote->joystickY; 

15. theJoy_x = G_remote->joystickX; 

16. the_gunElevation = G_remote->gunElevation; 

17. the_gunAzimuth = G_reniote->gunA 2 imuth; 

18. } 

19. 

20. // Update weapons delivery and fog modes 

21. the_button = G_remote->weaponsMode; 

22. the_fog = G_remote->environmentMode; 

23. 

24. //NEW - weapons fire and FTP info 

25. if ((G_remote->vehicleID.address.site == G_static_data->DIS_address.site) && 

26. (G_remote->vehicleID.address.host == G_static_data->DIS_address.host)) 

27. { 

28. // If the helo an SH60, let the panel fire weapons, regardless of who has control 

29. if (isaswheloveh(draw_data->type)) 

30. ( 

31. if(the_button& GULPRIMARY) 

32. firebuttonhit ( PRIMARY, G_drivenveh, draw_data); 

33. 

34. if ( the_button & GUI_SECONDARY ) 

35. firebuttonhit ( SECONDARY, G_drivenveh, draw_data); 

36. } // end if ASW helo 

37. 

38. //NEW - get FTP data for display to user 

39. draw_data->FTP_is_on = G_remote->FTPon; 

40. draw_data->FTP_X_posit = G_remote->FTPXposit; 
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41. draw_data->FTP_Y_posit = G_remote->FTPY posit; 

42. ) // end weps and FTP info 

43. 

44. ) // end there was a socket to read 

45. 

46. // If the Panel has control, update the vehicle’s control information 

47. if ( G_dynamic__data->control == REMOTE ) 

48. { 

49. control_data.thrust = the_thrust; 

50. control_data.pitch = the Joy _y; 

51. control_data.roll = the Joy_x; 

52. draw_data->look.hpr[HEADING] = the_gunAzimuth; 

53. draw_data->look.hpr[PITCH] = the_gunElevation; 

54. 

55. //Fire weapon if Panel has control 

56. if (the_button& GULPRIMARY ) 

57. firebuttonhit ( PRIMARY, G_drivenveh, draw_data); 

58. 

59. if (the_button & GULSECONDARY ) 

60. firebuttonhit (SECONDARY, G_drivenveh, draw_data); 

61. 

62. if (the_button & GULTERTIARY ) 

63. firebuttonhit (TERTIARY, G_drivenveh, draw_data); 

64. 

65. // If Panel in control, toggle targetting 

66. if ((the_button & GULTARGETING) != last_state ) 

67. { 

68. G_dynamic_data->targetting = !G_dynamic_data->targetting; 

69. target_ok = G_curtime; 

70. lasLstate = (the_button & GULTARGETING); 

71. } 

72. 

73. // If panel in control, toggle fog 

74. if ((the_fog & GULFOG ) != lastjog ) 

75. ( 

76. changed.fog = TRUE; 

77. lastjog = (the Jog & GULFOG ); 

78. ) 

79. }//end if control == REMOTE 

80. 

81. // Generate a GULMSG_DATA packet to send state info to Panel 

82. if ( sock_open ) 

83. { 

84. static int loop = 0; 

85. infoJo_go.heading = (float) (360.0f - (draw_data->posture.hpr[HEADING])); 

86. infoJo_go.pitch = (float) draw Jata->posture.hpr[PlTCH]; 

87. infojo_go.roll = (float) draw_data->posture.hpr[ROLL]; 
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88. info_to_go.throttleSelting = (float)control_data.thrust; 

89. info_to_go.gunAziinuth = (float) draw_data->look.hpr[HEADING]; 

90. info_to_go.gunElevation = (float) draw_data->look.hpr[PITCH]; 

91. info_to_go.positionX = (float) draw_data->posture.xyz[X]; 

92. info_to_go.positionY = (float) draw_data->posture.xyz[Y]; 

93. info_to_go.positionZ = (float) draw_data->posture.xyz[Z]; 

94. irtfo_to_go.vehicleID.address.site = G_static_data->DIS_address.site; 

95. info_to_go.vehicleID.address.host = G_static_data->DIS_address.host; 

96. info_to_go.altitude = (draw_data->altitude) * METER_TO_FOOT; 

97. info_to_go.velocity = draw_data->speed; 

98. 

99. //NEW - info to send to panel about FTP (not really needed) 

100. info_to_go.FTPon = the_FTP0n; 

101. info_to_go.FTPXposit = the_FTPXposit; 

102. info_to_go.FTPYposit = the_FTPYposit; 

103. 

104. loop++; 

105. 

106. // Write the socket to the network every application cycles 

107. if (loop >= 5 ) 

108. { 

109. socket_write ((char *) &info_to_go ); 

110. loop = 0; 

111. } // end loop 

112. } // end if socket_open 

113. } // end if remote exists 

114. #endif 
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APPENDIX B. SOURCE CODE PANEL MESSAGE CLASS 
(MESSAGE.C) 


2. // Function to write a PDU socket. If write fails, display error message, 

3. // close socket, and terminate program. 

5. void Message;:writeSocket() 

6 . { 

7. // Set pdu entity address to the npsnet session being controlled 

8. pdu.vehiclelD.address.host = G_data.npsnetAddress.address.host; 

9. pdu.vehicIelD.address.site = G_data.npsnetAddress.address.site; 

10. 

11. if (socket_write((char *) &pdu) != TRUE) 

12. { 

13. cerr « “socket failure, write failed” « endl; 

14. cerr « “Exiting program \n”; 

15. socket_close(); 

16. 

17. exit(O); 

18. } 

19. ) 

20. 

21. 

23. // Function to read a PDU socket and distribute the appropriate 

24, // information throughout the panel display. 

26. void Message;;readSocket() 

27. { 

28. 

29. static GUI_MSG_DATA *pdu_ptr; 

30. static struct readstat rstat; 

31. 

32. if ( (pdu_ptr = socket_read(&rstat)) == NULL) 

33. { 

34. //no pdu’s available to read 

35. ) 

36. else 

37. { 

38. if ((pdu_ptr->vehicleID.address.host == G_data.npsnetAddress.address.host) 

39. && (pdu_ptr->vehicleID.address.site == G_data.npsnetAddress.address.site)) 

40. { 
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42. 

43. 


// update the throttle 
theThrottle->updateThrottle(pdu_ptr); 


40. 

46. 

47. 

48. 

49. 

50. 

51. 

52. 

53. 

54. 

55. 

56. 

57. 

58. 

59. 

60. 
61. 
62. 

63. 

64. 

65. 

66 . 

67. 

68 . 

69. 

70. 

71. 

72. 

73. 

74. 

75. 

76. 

77. 

78. 

79. 

80. 
81. 
82. 

83. 

84. 

85. 

86 . 
87. 


// update the instrument component 

theInstrument->updateInstrumentDisplays (pdu_ptr, _pickVehlndex); 

// update the radar screen 
theViewscreen->updateScreen(pdu_ptr); 

// update the tactical map 
theMap->updateMap(pdu_ptr); 

} 


// Function to write a PDU socket based on throttle movement. First set 
// the throttle variable in GUI_MSG_DATA and then write the entire 
// socket structure. 


void Message: :throttleChanged(int throttle) 


pdu. throttles etting = float(throttle)/100.0; 
writeSocketO; 

) 


// Function to write a PDU socket based on gun azimuth movement. First 
// set the azimuth variable in GUI_MSG_DATA and then write the entire 
// socket structure. 


void Message::gunAzimuthChanged(mt azimuth) 

{ 


pdu.gunAzimuth = float(azimuth); 
writeSocketO; 


// Function to write a PDU socket based on gun elevation movement. 

// First set the elevation variable in GUI_MSG_DATA and then write the 
II entire socket structure. 


void Message::gunElevationChanged(int elevation) 


80 




88. pdu.gunElevation = float(elevation); 

89. writeSocketO; 

90. } 

91. 

92. 

94. II Function to set the vehicle based on user selection. Function 

95. // changes the global value of the index of the selected vehicle 

96. // from the radar screen. The stealth display will be updated 

97. // with the new value on the next timer increment within the 

98. // readSocket function. No writeSocket is required, since 

99. // the displayed information does not change the state of NPSNET 

100. // in any way 

102. void Message::pickVehicleChanged(int index) 

103. { 

104. _pickVehIndex = index; 

105. ) 

106. 

107. 

109. // Function to write a PDU socket based on joystick movement. 

110. // First set the values within the GUI_MSG_DATA structure for the 

111. // joystick inputs, then distribute the socket to NPSNET. 

113. void Message::joystickChanged(floatjoystickX, float joystickY) 

114. { 

115. pdu.joystickX = joystickX; 

116. pdu.joystickY = joystickY; 

117. writeSocketO; 

118. } 

119. 

120. 

121. //NEW 

123. // Function to write a PDU socket based on FPP position. 

124. // First set the values within the GUI_MSG_DATA structure for the 

125. // FTP, then distribute the socket to NPSNET. 

127. void Message:;FTPChanged(int on, float FTPX, float FTPY) 

128. ( 

129. // Set the pdu data fields 

130. pdu.FTPon = on; 

131. pdu.FTPXposit = FTPX; 

132. pdu.FTPYposit = FTPY; 

133. 

134. // Write the pdu to the net 
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135. writeSocketO; 

136. ) 

137. 

138. 

139. //********************************************************* 

140. // Functions to write a PDU socket based on weapon selections. 

141. // First set the values within the GUI_MSG_DATA structure for the 

142. // weapon inputs, then distribute the sockets to NPSNET. 

144. void Message:;targettingState(short state) 

145. I 

146. if (state) //targetting mode is on 

147. pdu.weaponsMode 1= GUI_TARGETING; 

148. else // targetting mode is off 

149. pdu.weaponsMode &= !(GUI_TARGETING); 

150. 

151. writeSocketO; 

152. ) 

153. 

154. 

155. void Message::primaryWeapon(short state) 

156. { 

157. if (state) // mode is on 

158. pdu.weaponsMode 1= GUI_PRIMARY; 

159. else //mode is off 

160. pdu.weaponsMode &= !(GUI_PRIMARY); 

161. 

162. writeSocketO; 

163. ) 

164. 

165. 

166. void Message;:secondaryWeapon(short state) 

167. { 

168. if (state) // mode is on 

169. pdu.weaponsMode 1= GUI_SECONDARY; 

170. else //modeis off 

171. pdu.weaponsMode &= !(GUI_SECONDARY); 

172. 

173. writeSocketO; 

174. ) 

175. 

176. 

177. void Message::tertiaryWeapon(short state) 

178. 1 

179. if (state) //mode is on 

180. pdu.weaponsMode 1= GUI_TERTIARY; 

181. else //mode is off 
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182. pdu.weaponsMode &= !(GUI_TERT1ARY); 

183. 

184. writeSocketO; 

185. ) 
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APPENDIX C. SOURCE CODE PANEL RADAR CLASS 
(RADAR.H) 


1. #ifndefRADAR_H 

2. tdefine RADAR_H 

3. 

4. #include <VkA'kComponent.h> 

5. #include <Sgm/GlxMDraw.h> 

6. 

7. #defme MAX.FTP 6 

8. fdefine MAX_SONOBUOYS 25 

9. fdefine MAX_SONO_RANGE lOOO.Of 

10. #define KrP_CAPTURE_RANGE SOO.Of 

11. 

12. class Radar: public VkComponent 

13. { 

14. 

15. public: 

16. Radar(const char *name. Widget parent); 

17. -RadarO; 

18. virtual const char *className(); 

19. 

20. void updateRadar(float posX, float posY, float hdg); 

21. void setRange(int); 

22. 

23. //NEW 

24. void FTPState(shott); 

25. void sonobuoyLaunch(short); 

26. 

27. protected: 

28. 

29. void ginit(GixDrawCallbackStruct *cb); 

30. void expose(GlxDrawCallbackStruct *cb); 

31. void resize(GlxDrawCallbackStruct *cb); 

32. void inputFTP(GlxDrawCallbackStruct *cb); 

33. void initialize_gl(); 

34. 

35. static void exposeCallback(Widget w, XtPointer clientData, XtPointer callData); 

36. static void ginitCallback(Widget w, XtPointer clientData, XtPointer callData); 

37. static void resizeCallback(Widget w, XtPointer clientData, XtPointer callData); 

38. static void inputCallback(Widget w, XtPointer clientData, XtPointer callData); 

39. 

40. void computeworldcoordinate(int, int, float *, float *); 
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41. void monitorNetO; 

42. void Update_map(); 

43. int pickVehicleO; 

44. void draw_stuff_on_map(void); 

45. void drawBoundariesO; 

46. 

47. //NEW - FTP/sonobuoy functions 

48. void drawHeadingBugO; 

49. void drawSonobuoysO; 

50. void drawFTPsO; 

51. void deleteFTP(int); 

52. 

53. //NEW - function to compute the 2D distance between 2 points 

54. float computeTheDist(float, float, float, float); 

55. 

56. private: 

57. 

58. //NEW - determines whether we are in add mode or delete mode 

59. short FTP_add_mode; 

60. 

61. //NEW - structure for the FTP’s position 

62. typedef struct 

63. { 

64. float x_posit; 

65. float y_posit; 

66. } FFP.POSIT; 

67. 

68. //NEW - structure for the FTP information 

69. typedef struct 

70. { 

71. int used; 

72. FTP_POSIT position; 

73. } FTP_INFO; 

74. 

75. //NEW - array to hold all FTPs 

76. FTPJNFO FTP_anay[MAX_FTP]; 

77. 

78. //NEW - structure for the sonobuoy’s position 

79. typedef struct 

80. i 

81. float sono_x_posit; 

82. float sono_y_posit; 

83. } SONO_POSIT; 

84. 

85. //NEW - structure for the sonobuoy information 

86. typedef struct 

87. { 
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88. int sono_used; 

89. SONO_POSIT sono_position; 

90. } SONOJNFO; 

91. 

92. //NEW - array to hold all sonobuoys 

93. SONOJNFO Sono_aiTay[MAX_SONOBUOYS]; 

94. }; 

95. 

96. extern Radar *theRadar; 

97. #endif 
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APPENDIX D. SOURCE CODE PANEL RADAR CLASS 
(RADAR.C) 


1. #include <st(lio.h> 

2. #inclu(le <stdlib.h> 

3. #uiclude <tnath.h> 

4. #include <stream.h> 

5. tinclude <iostream.h> 

6. 

7. #include “radar.H” 

8. #include “message.H” 

9. 

10. #include “entity.H” 

11. #include “netutil.H” 

12. #include “global.h” 

13. #include “fonts/fontdef.h” 

14. #include “constants.h” 

15. 

16. // Constants that define the GL state for the GL widget. 

17. static GLXconfig glxConfig [] = 

18. { 

19. {GLX_NORMAL, GLX_DOUBLE, TRUE}, 

20. {GLX_NORMAL,GLX_RGB,TRUE}, 

21. {GLX.NORMAL, GLX_ZS IZE, GLX_NOCONFlG}, 

22. {0,0,0} 

23. }; 

24. 

25. // set up initial radar center position as center of the world 

26. float centerX = (G_data.maxX - G_data.minX)/2.0; 

27. float centerY = (G_data.maxY - G_data.minY)/2.0; 

28. float centerHdg = 0.0; 

29. 

30. static short pickbuffer[MAX_VEH]; 

31. 

32. //NEW - variables to determine which sonobuoy is next 

33. static int next_Sonobuoy = 0; 

34. 

35. float _range= 1.0; 

36. float _posX; 

37. float _posY; 

38. float _hdg; 

39. 

40. 


Radar *theRadar = NULL; 






41. 

42. Radar::Radar(const char *name. Widget parent) : Vk;Component(name) 

43. { 

44. theRadar = this; 

45. int count; 

46. Arg args[10]; 

47. 

48. count = 0; 

49. 

50. //NEW - initialize ASW mode to off 

51. FTP_add_mode = 0; 

52. 

53. //NEW - initialize values for the FTP array 

54. for(intax = 0;ax<MAX_FTP;ax++) 

55. { 

56. FTP_array[ax].used = FALSE; 

57. FTP_array[ax].position.x_posit = O.Of; 

58. FTP_array[ax].position.y_posit = O.Of; 

59. } 

60. 

61. //NEW - initialize values for the sonobuoy array 

62. for(ax = 0; ax < MAX_SONOBUOYS; ax++) 

63. { 

64. Sono_array[ax].sono_used = FALSE; 

65. Sono_array[ax].sono_position.sono_x_posit= O.Of; 

66. Sono_array[ax].sono_position.sono_y_posit = O.Of; 

67. } 

68 . 

69. // replace the default translation table for the GlxNinputCallback 

70. // with a new one that only responds to mouse button down events, 

71. // rather than the default of all button and keyboard events. 

72. String translations = “<BtnDown>:glxlnput()”; 

73. 

74. XtSetArg(args[count], GlxNglxConfig, glxConfig); count++; 

75. 

76. // use the newly defined translation table to replace to default one 

77. XtSetArg(args[count], XmNtranslations, XtParseTranslationTable 

78. (translations)); count++; 

79. 

80. _baseWidget = GlxCreateMDraw(parent, _name, args, count); 

81. 

82. XtAddCallback(_baseWidget, GlxNexposeCallback, &Radar:;exposeCallback, 

83. (XtPointer) this); 

84. XtAddCallback(_baseWidget, GlxNginitCallback, &Radar::ginitCailback, 

85. (XtPointer) this); 

86. XtAddCallback(_baseWidget, GlxNresizeCallback, &Radar::resizeCallback, 

87. (XtPointer) this); 
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88. XtAddCallback(_baseWidget, GlxNinputCallback, &Radar;:inputCallback, 

89. (XtPointer) this); 

90. } 

91. 

92. void Radar::exposeCalJback(Widget, XtPointer, XtPointer callData) 

93. { 

94. GlxDrawCallbackStruct *cb = (GlxDrawCallbackStruct *) callData; 

95. 

96. GLX winset(XtDisplay(theRadar->baseW idget()),XtW indow(theRadar-> 

97. baseWidgetO)); 

98. theRadar->expose(cb); 

99. } 

100. 

101. void Radar::ginitCallback(Widget, XtPointer, XtPointer callData) 

102. { 

103. GlxDrawCallbackStruct *cb = (GlxDrawCallbackStruct *) callData; 

104. 

105. GLXwinset(XtDisplay(theRadar->baseWidget()), XtWindow(theRadar-> 

106. baseWidgetO)); 

107. theRadar->ginit(cb); 

108. } 

109. 

110. void Radar:;resizeCallback(Widget, XtPointer, XtPointer callData) 

111. ( 

112. GlxDrawCallbackStruct *cb = (GlxDrawCallbackStruct *) callData; 

113. 

114. GLXwinset(XtDisplay(theRadar->baseWidget()), XtWindow(theRadar-> 

115. baseWidgetO)); 

116. theRadar->resize(cb); 

117. } 

118. 

119. void Radar::inputCallback(Widget, XtPointer, XtPointer callData) 

120. { 

121. //NEW - The panel is in ASW vehicle mode and new FTP’s are to be added, 

122. // so make the inputFTP callback 

123. GlxDrawCallbackStruct *cb = (GlxDrawCallbackStruct *) callData; 

124. GLXwinset(XtDisplay(theRadar->baseWidget()), XtWindow(theRadar-> 

125. baseWidgetO)); 

126. theRadar->inputFTP(cb); 

127. 

128. // We can’t add FTP’s, so change the pick vehicle for stealth 

129. theMessage->pickVehicleChanged (theRadar->pickVehicle()); 

130. 

131. } 

132. 

133. 





135. void Radar::ginit(GlxDrawCallbackStruct *) 

136. { 

137. setRange(lOO); 

138. initialize_gl(); 

139. 

140. // wait until the gl window is initialized to start drawing to 

141. // it within the timer loop, otherwise ...core dump... 

142. theMessage->_timer->start(); 

143. 

144. // start listening to the net for entities to display 

145. theRadar->monitorNet(); 

146. } 

147. 

148. Radar;;~Radar() 


153. const char *Radar::className() 


return “Radar”; 


, void Radar: :expose(GlxDrawCallbackStruct ♦) 


161. updateRadar(G_data.world_x_size/2.0, G_data.world_y_size/2.0, 0.0); 


//*********■ 
void Radar;:resize(GlxDrawCallbackStruct *cb) 

{ 

viewport(0, (Screencoord) cb->width-l, 

0, (Screencoord) cb->height-l); 

updateRadar(G_data.world_x_size/2.0, G_data.world_y_size/2.0, 0.0); 


//NEW - this designates the location for a new FTP 
void Radar;;inputFTP(GlxDrawCallbackStract *cb) 

i 

// Variables for the location of the FTP in world coordinates 
float wx, wy; 

o be input 
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182. // Find out which FTP is the next to be assigned 

183. while ((next JTP < MAX_FTP) && (FTP_array[next_FTP].used == TRUE)) 

184. next_FTP++; 

185. 

186. if (theRadar >FTP_add_mode) 

187. { 

188. if (next_FTP != MAX_FTP) 

189. { // one is available, so add it; otherwise do nothing 

190. 

191. // Call computeworldcoordinateO to convert the screen coordinate 

192. // on the radar screen to terrain coordinates 

193. computeworldcoordinate((S creencoord)cb->event->xbu tton.x, 

194. (Screencoord)cb->event->xbutton.y, &wx, &wy); 

195. 

196. //Set the fields of the FTP array 

197. FTP_array[next_FTP].used = TRUE; 

198. FTP_array(next_FTP].position.x_posit = wx; 

199. FTP_array[next_FTP].p)osition.y_posit = wy; 

200. 

201. // the top priority FTP changed, so send message to NPSNET 

202. if (next_FTP == 0) 

203. theMessage -> FTPChanged(FTP_atTay[next_FTP].used, 

204. FTP_array[next_FTP].position.x_posit, 

205. FTP_array[next_FTP].position.y_posit); 

206. 

207. } // end if next_FTP != MAX.FTP 

208. 

209. } // end if FTP_add_mode on 

210. 

211. else // FTP add mode is off, so let the user pick an FI'P and delete it 

212. { 

213. // Call computeworldcoordinateO to convert the screen coordinate 

214. // on the radar screen to terrain coordinates 

215. computeworldcoordinate((Screencoord)cb->event->xbutton.x, 

216. (Screencoord)cb->event->xbutton.y, <&wx, &wy); 

217. 

218. forfint ix=0;ix<MAX_FTP;ix++) 

219. { 

220. // If the FTP got picked, delete it 

221. if ((( wx >= (FTP_array [ix].position.x_posit - (_range/20.0f))) && 

222. ( wx <= (FTP_array[ix].position.x_posit + (_range/20.0f)))) && 

223. (( wy >= (FTP_array[ix].position.y_posit - (_range/20.0f))) && 

224. ( wy <= (FTP_array[ix).position.y_posit + (_range/20.0f))))) 

225. deleteFTP(ix); 

226. ) // end try to delete an FTP 

227. 

228. }//end else state 
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229. 

230. ) // end inputFTPO 

231. 

232. //******************************************************♦****= 

233. void Radar;;initialize_gl() 

234. { 

235. float scmaspect; //aspect ratio value 

236. long xscmsize; //size of screen in x used to set globals 

237. 

238. xscmsize = getgdesc(GD_XPMAX); // get/set screen size[/aspect] 

239. if (xscmsize == 1280) 

240. { 

241. keepaspectfS, 4); 

242. scmaspect = 1.25; 

243. ) 

244. else if (xscmsize == 1023) 

245. { 

246. keepaspect(4,3); 

247. scmaspect = 1.34; 

248. ) 

249. else 

250. ( 

251. fprintf(stderr, “Something’s EXTREMELY wrong; “); 

252. fprintf(stderr, “xscmsize=%d\n”, xscmsize); 

253. exit(-l); 

254. ) 

255. 

256. // Always turn subpixel tme. 

257. subpixel(TRUE); 

258. 

259. //define the font 

260. fontdef(lL, G_data.hud_font_fiie); 

261. 

262. doublebufferO; 

263. } 

264. 

265. //***********************************************************:< 

266. void Radar;:monitorNet() 

267. { 

268. G_data.doing = MONITOR; 

269. 

270. //there will be no outgoing PDUs 

271. G_data.net = RECEIVE; 

272. 

273. //stop generating PDUs, if we are generating them 

274. for(int ix =0;ix<MAX_VEH;ix++) 

275. { 
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276. if (G_veWist[ix].vehptr != NULL) 

277. { //is it an active entity 

278. if(G_vehlist[ix].vehptr->get_C2_flagO) 

279. { 

280. //we have to deactivate the vehicle 

281. deactiveate entity(ix); 

282. } 

283. } 

284. } 

285. } 

286. 

288. // taken from the file inst_ptr.c to draw the artificial horizon 

289. void Radar::updateRadar(float posX, float posY, float hdg) 

290. { 

291. //set the global position x and y based on the socket input 

292. _posX = posX; 

293. _posY = posY; 

294. _hdg = hdg; 

295. 

296. // set the correct window to draw the radar into 

297. GLXwinset(XtDisplay(theRadar->baseWidget()), XtWindow(theRadar-> 

298. baseWidgetO)); 

299. 

300. // set the background color for the radar screen 

301. RGBcolor(0, 0, 0); 

302. clear/); 

303. 

304. // display only the selected range centered at posX and posY 

305. ortho2(_posX - _range, _posX + _range, 

306. _posY - _range, _posY + _range); 

307. 

308. // translate (-_posX, -_posY, 0) to place origin at current position 

309. translate (_posX, _posY, 0.0); 

310. 

311. //NEW - real radar screens don’t rotate, so don’t rotate (heading); 

312. // rot(_hdg, ‘z’); 

313. 

314. // translate (posX, posY, 0) to return view back to normal 

315. translate (-_posX, -_posY, 0.0); 

316. 

317. // draw radar range rings 

318. linewidth(l); 

319. cpack (OxOOffOOOO); 

320. circ(posX,posY,20000.0f); 

321. cpack (OxOOOOffOO); 

322. circ(posX,posY,10000.0f); 


95 




323. cpack (OxOOOOffff); 

324. circ(posX,posY,5000.0f); 

325. cpack (OxOOOOOOff); 

326. circ(posX,posY,1000.0f); 

327. linewidth(l); 

328. 

329. drawBoundariesO; 

330. Update_map(); 

331. 

332. ) // updateRadar(floatdloat,float) 

333. 

335. void Radar::Update_map() 

336. { 

337. static int count = 0; 

338. static double oldtime =0.0; 

339. 

340. //if the network is open, update the time 

341. if(G_data.net != CLOSED) 

342. { 

343. 

344. G_data.sim_time = pfGetTimeO; 

345. if(oldttme < G_data.sim_time) 

346. G_data.delta_time = G_data.sim_time - oldtime; 

347. else // time reset 

348. G_data.delta_ttme = 0; 

349. oldtime = G_data.sim_time; 

350. 

351. //move all of the icons 

352. update_entities(); 

353. 

354. if(G_data.net != OPEN) 

355. { 

356. //where are all of the entities 

357. draw_stuff_on_map(); 

358. } 

359. } 

360. 

361. if(G_data.net != CLOSED) 

362. { 

363. parse_net_pdus(); 

364. } 

365. 

366. swapbuffersQ; 

367. count ++; 

368. } 

369. 
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370. 

371. //**************************^:********************^ 

372. void Radar: :draw_stuff_on_map() 

373. // draws the new and improved 2D map on the screen 

374. i 

375. int ix, inttype; 

376. float pos[3]; 

377. char text[40]; 

378. 

379. //use the pretty pictures 

380. font(l); 

381. 

382. for(ix=0;ix<MAX_VEH;ix++) 

383. { 

384. if(G_vehlist[ix].vehptr == NULL) continue; 

385. pfCopyVec3(pos,G_vehlist[ix].vehptr->getposition()); 

386. inttype = G_vehlist[ix].type; 

387. if (inttype < 1 ) 

388. sprintf(text,”%c”,’?’); 

389. else if ((inttype >= 1) && (inttype <= 5)) 

390. sprintf(text,”%c”,’J’); 

391. else if ((inttype >= 6) && (inttype <= 10)) 

392. sprintf(text,”%c”,’E’); 

393. else if ((inttype >=!!)&& (inttype <= 20)) 

394. sprintf(text "%c”,’Q’); 

395. else if ((inttype >= 20) && (inttype <= 25)) 

396. sprintf(text,"%c”,’R’); 

397. else if ((inttype >= 26) && (inttype <= 30)) 

398. sprintf(text,”%c”,’C’); 

399. else if ((inttype >=31) && (inttype <= 35)) 

400. sprintf(text ”%c”,’?’); 

401. else if ((inttype >= 36) && (inttype <= 40)) 

402. sprintf(text,”%c”,’A’); 

403. else if ((inttype >= 41) && (inttype <= 45)) 

404. sprintf(text,”%c”,’r); 

405. else if ((inttype >= 46) && (inttype <= 50)) 

406. sprintf(text ”%c”,’r); 

407. else if ((inttype >= 51) && (inttype <= 55)) 

408. sprintf(text ”%c”,’G’); 

409. else if ((inttype >= 56) && (inttype <= 57)) 

410. sprintf(text,”%c”,’A’); 

411. else if ((inttype >= 58) && (inttype <= 60)) 

412. sptlntf(text,”%c”,’r); 

413. else if ((inttype >= 61) && (inttype <= 70)) 

414. sprintf(text,”%c”,’B’); 

415. // DON’T PRINT SUBS ON DISPLAY 

416. else if ((inttype >=71) && (inttype <= 75) ) 
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417. sprintf(text,”%c”,’ ‘); 

418. else if ((inttype >= 76) && (inttype <= 80)) 

419. sprintf(text,”%c”,’?’); 

420. else if ((inttype >= 81) && (inttype <= 95)) 

421. sprintf(text ”%c”,’&’); 

422. else if ((inttype >= 96) && (inttype <= 99)) 

423. sprintf(text ”%c”,’?’); 

424. else if ((inttype >= 100) && (inttype <= 199)) 

425. sprintf(text,”%c”,7’); 

426. else 

427. sprintf(text,”%c”,’x’); 

428. 

429. 

430. switch(G_vehlist[ix].vehptr->getforce()) 

431. { 

432. case ForceID_Blue: 

433. cpack(0xffff8f00); 

434. break; 

435. case ForceID_Red: 

436. cpack(OxffOOOOff); 

437. break; 

438. case ForceID_White: 

439. cpack(Oxffffffff); 

440. break; 

441. default: 

442. cpack(OxffOOffOO); 

443. break; 

444. } 

445. 

446. cmov2(pos[X],pos[Y]); 

447. charstr(text); 

448. ) 

449. 

450. /^ack to the normal text 

451. font(O); 

452. 

453. //NEW - this calls the function to draw the heading bug 

454. drawHeadingBugO; 

455. 

456. //NEW - draw the sonobuoys and their bearing lines 

457. drawSonobuoysO; 

458. 

459. //NEW - draw the FTPs 

460. drawFTPsO; 

461. } 

462. 
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464. intRadar;:pickVehicle() 

465. // draws pick map on the radar screen to evaluate mouse input 

466. { 

467. static int ix; 

468. static float pos [3 ]; 

469. static char text[40]; 

470. static int numofhits; 

471. 

472. // set the correct window to draw the pick map into 

473. GLXwinset( XtDisplay(theRadar->baseWidget()), XtWindow(theRadar-> 

474. baseWidgetO)); 

475. 

476. //set up the pick buffers 

477. pushmatrixO; 

478. pick(pickbuffer,MAX_VEH); 

479. 

480. // **************** Set up the window ****************** 

481. ortho2(_posX - _range, _posX + _range, 

482. _posY - _range, _posY + _range); 

483. 

484. // translate (-_posX, -_posY, 0) to place origin at current position 

485. translate (_posX, _posY, 0.0); 

486. 

487. // route (heading); 

488. rot(_hdg, ‘z’); 

489. 

490. // translate (posX, posY, 0) to return view back to normal 

491. translate (-_posX, -_posY, 0.0); 

492. 

493. font(l); 

494. 

495. for(ix=0;ix<MAX_VEH;ix++) 

496. { 

497. if(pos,G_vehlist[ix].vehptr == NULL) continue; 

498. pfCopyVec3(pos,G_vehlist[ix].vehptr->getposition()); 

499. 

500. //store the location 

501. loadname((short)ix); 

502. 

503. //figure out where the guy is 

504. sprintf(text,”%c”,’E’); 

505. cpack(Oxffffffff); 

506. cmov2(pos[X],pos[Y]); 

507. charstr(text); 

508. } 

509. font(O); 

510. 
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511. //number of things picked from the screen 

512. numofhits = (rnt)endpick(pickbuffer); 

513. 

514. if(numofhits > 0) 

515. { 

516. popmatrixO; 

517. return (pickbuffer[l]); 

518. ) 

519. else // no vehicle was selected 

520. { 

521. popmatrixO; 

522. return (0); 

523. } 

524. ) 

525. 

526. //NEW - changed from old code 

528. // computeworldcoordinate - 

529. // This function computes the world coordinate corresponding to the 

530. // input mouse coordinate. 

531. // The input mouse coordinate is in the X window system so the 

532. // origin is in the upper left comer. 

533. // 

534. // Inputs: 

535. // int x,y = input mouse coordinate in X coordinate system. 

536. // 

537. // Outputs: 

538. // float *wx, *wy = returned world coordinate. 

539. // 

540. 

541. void Radar::computeworldcoordinate(int x, int y, float *wx, float *wy) 

542. { 

543. // Find the world x coordinate 

544. *wx = (( 2 * _range )/324.0f) * (x) + (_posX - _range ); 

545. 

546. // Find the world y coordinate 

547. *wy = (( 2 * _range )/324.0f) * ((324.0f - 1) - y) + ( _posY - _range ); 

548. } 

549. 

550. //************************************************************** 

551. void Radar: :setRange(int range) 

552. { 

553. //set range as a function of the % of the world size 

554. //NEW - only show the shortest distance that can be seen 

555. if (G_data.maxX < G^data.maxY) 

556. _range = ((G_data.maxX * float(range) / 100.0) / 2.0); 

557. else 
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558. _range = ((G_data.maxY * float(range) /100.0) / 2.0); 

559. 

560. if (_range < 1.0) 

561. _range=1.0; 

562. } 

563. 

565. // draw the boundaries of the world 

566. void Radar::drawBoundaries() 

567. { 

568. static float p[4][2]; 

569. p[0][0] = G_data.minX; 

570. p[0][l] = G_data.minY; 

571. 

572. p[l][0] = G_data.minX; 

573. p[l][l] = G_data.maxY; 

574. 

575. p[2][0] =G_data.maxX; 

576. p[2][l] = G_data.maxY; 

577. 

578. p[3][0] = G_data.maxX; 

579. p[3][l] = G_data.minY; 

580. 

581. cpack(OxFF888888); 

582. 

583. bgnclosedlineO; 

584. v2f(p[0]); 

585. v2f(p[l]); 

586. v2f(p[2]); 

587. v2f(p[3]); 

588. endclosedlineO; 

589. } 

590. 

591. //NEW - all FTP functionality 

592. // This function turns on/off the pick functions for FTPs 

593. void Radar::FTPState(short state) 

594. { 

595. // Allow the user to input a new a FTP 

596. if (state) 

597. theRadar->FTP_add_mode = 1; 

598. 

599. // Allow the user to pick a FTP and delete it 

600. else 

601. theRadar->FTP_add_mode = 0; 

602. } 

603. 

604. 
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605. //NEW - Draw the heading bug 

606. void Radar::drawHeadingBugO 

607. { 

608. // 2x2 array for starting point and endpoint for the heading bug 

609. float head_vec[2][2]; 

610. 

611. // This is the starting point, the center of the display 

612. head_vec[0][0] = _posX; 

613. head_vec[0][l] = _posY; 

614. 

615. // The endpoint is in the direction of heading, scaled so that 

616. // it appears the same length no matter what the range setting of 

617. // the radar is. 

618. head_vec[l][0] = _posX + ((_range/5.0f) * sinf(_hdg * DEG_TO_RAD)); 

619. head_vec[l][l] = _j)osY + ((_range/5.0f) * cosf(_hdg * DEG_TO_RAD)); 

620. 

621. // draw the heading bug 

622. linewidth(l); 

623. cpack (OxOOffffff); // color white 

624. bgnlineO; 

625. v2f(head_vec[0]); 

626. v2f(head_vec[l]); 

627. endlineO; 

628. ) 

629. 

630. 

631. //NEW - this function adds a new sonobuoy to the sonobuoy array 

632. void Radar::sonobuoyLaunch(short state) 

633. { 

634. // State is true so add a new sonobuoy; otherwise, do nothing 

635. if ((state) && (next_Sonobuoy < MAX.SONOBUOYS)) 

636. { 

637. Sono_array[next_Sonobuoy].sono_used = TRUE; 

638. Sono_array[next_Sonobuoy].sono_position.sono_x_posit = _posX; 

639. Sono_array[next_Sonobuoy].sono_position.sono_y_posit = _posY; 

640. next_Sonobuoy++; 

641. } 

642. } 

643. 

644. 

645. //NEW - this draws the sonobuoys and lines of bearing to the sub 

646. void Radar::drawSonobuoys() 

647. { 

648. // This if for the font to be used 

649. char text[40]; 

650. 

651. cpack(OxOOOOffOO); // color green 
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652. 

653. // Draw the sonobuoys and their bearing lines 

654. for(int ax = 0; ax < MAX_SONOBUOYS; ax++) 

655. ( 

656. // Variables for distance calculation 

657. float dist_to_contact = MAX_SONO_RANGE; 

658. float temp_distance = O.Of; 

659. 

660. // Variable for which ID we are going to target 

661. int contact JD =-1; 

662. 

663. // Array to hold the endpoints of bearing lines 

664. float bearing_line[2][2] = (0}; 

665. 

666. // Arrays for target position 

667. float tatget_pos[3], temp_pos[3]; 

668. 

669. if (Sono_array[ax].sono_used == TRUE) 

670. { 

671. // Sonobuoy is the first point of the bearing line 

672. bearing_line[0][0] = Sono_arTay[ax].sono_position.sono_x_posif, 

673. bearingjine[0][l] = Sono_array[ax].sono_position.sono_y_posit; 

674. 

675. // First draw the sonobuoy symbol 

676. font(l); 

677. sprintf(text,”%c”,’0’); 

678. cmov2(bearing_line[0][0], bearingJine[0][l]); 

679. charstr(text); 

680. 

681. // Now draw the bearing line to the target 

682. for(int bx = 0; bx < MAX_VEH; bx++) 

683. ( 

684. if ((G_vehlist[bx].vehptr != NULL) && 

685. (G_vehlist[bx].vehptr->gettype() == SUBMERSIBLE)) 

686. { // this is a SUB, so find if it is the closest 

687. pfCopyVec3(temp_pos, G_vehlist[bx].vehptr->getposition()); 

688. temp_distance = computeTheDist(bearing_line[0][0], 

689. bearing_line[0][l], 

690. temp_pos[X], temp_pos[Y]); 

691. 

692. // shorter distance test 

693. if (temp_distance < dist_to_contact) 

694. 1 // it is closer, so target it 

695. pfCopyVec3(target_pos, temp_pos); 

696. contactJD = bx; 

697. dist_to_contact = temp_distance; 

698. 
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} // end if closer 


700. 

701. } // end if this is a sub 

702. 

703. ) // end search for closest SUB to draw to 

704. 

705. if (contact_ID != -1) 

706. { // we have the closest contact, so draw the bearing line 

707. // Target is the endpoint of the bearing line 

708. bearing_line[l][0] = target_pos[X]; 

709. bearing_line[l][l] = target_pos[Y]; 

710. 

711. // Draw the bearing line 

712. font(0); 

713. linewidth(l); 

714. bgnlineO; 

715. v2f(bearingjine[0]); 

716. v2f(bearing_line[l]); 

717. endlineO; 

718. 

719. ) // end if we have a contact 

720. 

721. ) // end if the sonobuoy is to be drawn 

722. 

723. } // end for all possible sonobuoys 

724. 

725. ) // end drawSonobuoysO 

726. 

727. 

728. //NEW - this draws the sonobuoys and lines of bearing to the sub 

729. void Radar::drawFTPs() 

730. { 

731. // This if for the font to be used 

732. char text[40]; 

733. 

734. // First check to see if the vehicle is close enough to 

735. // capture the #1 FTP; is so, delete and launch a sonobuoy 

736. if ((FTP_array[0].used == TRUE) && 

737. ((computeTheDist(_posX, _posY, 

738. FTP_array[0].position.x_posit, 

739. FTP_array[0].position.y_posit)) 

740. <= FTP__CAPTURE_RANGE )) 

741. ( 

742. deleteFTP(O); 

743. sonobuoyLaunch(l); 

744. } // end capture FTP 

745. 
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746. // Draw the FTPs 

747. font(l); 

748. cpack(OxOOffOOfD; H color cyan 

749. for(int cx = 0; cx < MAX_FTP; cx++) 

750. { 

751. // Only put it on the screen if it is active 

752. if (FrP_array [cx].used == TRUE) 

753. { 

754. // Designate the FTP font to be used in order of priority 

755. if(cx==0) 

756. sprintf(text,”%c”,’4’); 

757. elseif(cx== 1) 

758. sprintf(text,”%c”,’5’); 

759. else if (cx == 2) 

760. sprintf(text ”%c”,’6’); 

761. elseif(cx==3) 

762. sprintf(text,”%c”,’7’); 

763. elseif(cx==4) 

764. sprintf(text,”%c”,’8’); 

765. else 

766. sprintf(text,”%c”,’9’); 

767. 

768. // Put the character in the correct radar position 

769. cmov2(FTP_array [cx] .position.x_posi t, 

770. FTP_array[cx].position.y_posit); 

771. charstr(text); 

772. } // end if FTP is used 

773. 

774. } // end for all possible sonobuoys 

775. font(O); 

776. 

777. ) // end drawFTPsO 

778. 

779. 

780. //NEW - this deletes the selected FTP and changes the priority 

781. // of those that remain 

782. void Radar;:deleteFTP(int FTPid) 

783. { 

784. // The number deleted is the top priority FTP, so send 

785. // new message to NPSNET 

786. if ((FTPid == 0) && (FTP_arTay[FTPid].used = TRUE)) 

787. theMessage-> FTPChanged(FTP_array[FTPid + l].used, 

788. FTP_array [FTPid + l].position.x_posit, 

789. FTP_array [FTPid + l].position.y_posit); 

790. 

791. // Rearrange the rest of the array 

792. while (FTPid < (MAX__FTP - 1)) 
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793. { 

794. FTP_array[FrPid] = FTP_array[FTPid + 1]; 

795. FTPid++; 

796. } // end rearrange FTPs 

797. 

798. // Set the last FTP to unused 

799. FTP_array[FTPid].used = FALSE; 

800. 

801. }//end deleteFTPO 

802. 

803. 

804. //NEW - used to calculate the 2D distance between 2 points using the 

805. // Pythagorean theorem 

806. float Radar::computeTheDist(float from_x, float from_y, 

807. float to_x, float to_y) 

808. { 

809. retum(sqrt(((to_y - from_y) * (to_y - from_y)) + 

810. ((to_x - from_x) * (to_x - from_x)))); 

811. ) 
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